You've had more than eight years, you're still here, and it's still not fixed.

( Haskell )

Test suite tests different specs than are in the Description. Inputs of length 1 are special-cased in clear contradiction of the description.

Specs are still incomplete. How does cutting an outlier influence earlier values? ( They may now be outliers. ) Is cutting outliers strictly left-to-right, iterative, right-to-left, or does it only happen in original windows?

How can the example still have the outlier 3 in it?

Description is incomplete. Examples are not specifications; the description should be complete without them. Even the values that the example introduces ( threshold, window ) are, again, unspecified. They might be function arguments, but, again, the description does not specify that. Initial code is not specs either!

approved by someone

Shall we not do this? Please author in English. This is documented.

For simplicity, treat the input as case-insensitive, but return the original casing of the word.

How is this the simplest version of the problem? You just doubled the number of vowels.

If you think adding case insensitivity to a regex is the simplest solution, please consider those that would not solve this with a regex.

I don't mind the spec so much, but please lose the "for simplicity". Alternatively, specify all lowercase inputs. That would not be a bad option for an estimated 7kyu.

The fact that there exist multiple duplicate approved kata doesn't mean we should allow duplicate Beta kata to sprawl. ( Look up "whataboutism". )

Cleaning up duplicates amongst approved kata is a whole other project than reviewing Beta kata. It's being done, but it takes time ( years! ).

That said, I don't necessarily agree this is a duplicate, but, not being French myself, I would tend to defering to Blind on this.

How bad is that? Specify iterable instead of list ( the output format currently isn't even specified ), and you allow for ( modern ) idiomatic solutions.

But it does interfere with native behaviour ( for .. in ). Non-enumerability should be specified and tested.

( JS )

indents in test suite ( random tests part ) are not correct. this is not optimally maintainable. please follow CW Coding Guidelines. ( you may have mixed spaces and tabs. )

I found out the digits are encoded as base-10 numbers. This is not very intuitive, given the explicit "digit" in the title. It's a valid ( and perfectly reasonable ) choice! but specify it explicitly.

Also, the ( JS ) Example tests did not even make it clear. Consider adding a test that showcases this spec.

How is the last digit to be encoded, especially for bases over 36 ? I could probably glean this from the example tests, but it should be specified in the description.