Points probably should be namedtuples in Python. Using hashmaps for a couple of fixed keys looks bad.

• Use appropriate datatypes.

String is almost never a good way to tuple up values, and it isn't here. (Int,Bool) ( encoded as an Array, because JS doesn't have tuples ) would be appropriate.

• Ask for consistent return datatypes.

Stringifying things does not mean you are now suddenly asking for consistent ones. You should have asked for (Int,Bool), and that can never express the condition that there is no answer that fits that pattern. Expecting an Error to be thrown, or maybe expecting [], null or undefined ( though there are people with whom those choices will also get you in hot water ) would have been better. I think Error is best, but I'd say an empty value like one of the other three is marginally acceptable. ( It would be a ++Good Thing if you could explain the differences between them in the context of this kata, were you to use any of them. )

Both point are largely academic IMO. I don't think the kata offers sufficient novelty and interest to invest time in fixing it. Everything that this kata is asking for has been done ( and arbitrarily combining unrelated tasks is not a good thing either ).

Minor point: JS by convention uses camelCase ( except for constants and constructors ). "LCN" should have been "lcn" by that standard. Please adhere to this convention.

Random tests can generate [] as an input.

This is a problem.

You can't use normal equality with floating point values ( and rounding is not going to be a solution ); you have to allow an error margin. Write your own wrapper specific for your output encoding ( which is also bad, bad, bad ).

Returning inconsistent datatypes is not a best practice.