I don't really want to argue about this anymore, so this will be my last response to this thread. The translator's responsibility is to translate as accurately as possible in a way that fulfills all of the specs laid out in the kata description and in a way that makes sense for the target language. That means that if a description specifies that the code will test integers of a large size, then it makes sense to use bigint in Dart, while it doesn't make sense to do the same in python because there is no bigint analogue in python (the language handles arbitrarily large numbers automatically). However, it doesn't make sense to use bigint in dart if the kata never tests large integers. I can't believe I have to say this. Of course, you shouldn't use bigint in dart kata where it is not needed.

In this case, there is no need to have tests in python which test all different sizes of unicode characters because python automatically handles that for the programmer in the background. There is very little that a python programmer could do to fail such tests while passing the others, so these tests would be pointless to add because they would not be testing anything more than what the other tests already test for. It is not the python translation's responsiblilty to be the "gold standard" for every language that a language might be translated to, and it certainly isn't necessary to add extra tests to python just because they might make sense in some other language. Plenty of languages have features, requirements, and work in ways that are incompatible with python, and so python should not necessarily be the basis for all other translations. The burden of producing a good translation for a target language lies entirely with the author of that translation. You should not blame the python translation because your dart translation failed to test for non-BMP codepoints when it should have. It certainly does not warrant an issue that python does not include these tests, because in python, they would be extra noise and not add anything of value to the kata.

As trashy_incel said above, this kata has a lot of problems that would require a lot of work to fix. The translations are all over the place. However, trying to lay the blame on one of the few languages that doesn't have this flaw because of the way the language itself works is asinine.

The translator's responsibility is to translate kata as accurately as possible without violating the author's intentions. There's no mention of adding any tests. If all tests work properly in the target language, according to your logic, a translator translating from Python to Dart should use the bigInt type instead of int when using numbers in kata, even if Python doesn't have a number greater than int. The responsibility lies with the kata author. The author should clearly state all requirements for kata. If Python at least had fixed tests for the emojis from the description, this would solve the problem.

That's on the translator and the person who approves the translation. This is an old kata, so standards have become tighter since this came out.

No, people wouldn't ask this question; most people wouldn't even know about it, but translators would see that such tests exist and would understand that these tests are needed, or at least would think about the need for these tests.

But translations should be done according to the specs of the kata, taking the target language into account. They should not be done necessarily as a 1:1 translation from one language into another (although, for many kata, this will be the case). The same specs should be tested for, and this might look different in different languages depending on the kata. Imagine if this kata was written today and python was the first language it was written in, people would be questioning why the author is bothering to test for all these different unicode characters when python handles them all under the hood anyway.

if a Python solution works for ASCII strings, are tests for Unicode strings still needed?

Yes, they're needed, at the very least, to have a common structure for all languages. And as I said above, people prioritize Python, which means most translations will be done with Python. This means if Python doesn't have a test, it won't be in another translation.
If I'd known that checking for all Unicode characters was necessary, I wouldn't have done the Dart translation in this form. It turns out the work was wasted because the Python version is different from the others, and how many more such useless jobs will be done by other translators?

I vote to retire this kata altogether, if it's still possible to do those things. There are too many translations, each doing its own thing, it's overranked so we will have plenty of noisy "too easy for 5-kyu lol" comments (there are already dozens of them), the Unicode handling is impossible to specify due to edge cases like "ẞ".toLowerCase() === "ß" but "ß".toUpperCase() !== "ẞ", etc. This kata causes too many maintenance issues.

Additionally, I believe that the requirement to "handle any Unicode codepoint" was not grounded by any actual, interesting requirement, and I think that it was just added ad-hoc at some point just for fun. Working with generic unicode strings is difficult, and without library support, it's close to impossible to specify, let alone to implement well without large hardcoded Unicode tables, hardcoded cases, etc. Testing it is also very difficult. I do not like this requirement and I think it is not a good one. I would personally get rid of it and narrow it to some well defined set of characters (ascii, or maybe some unicode class), and get rid of generic handling of anything.

I believe that this statement is based on how character strings are represented internally in Python, and how indexing operations are handled in Python. The point is, mystring[0] will always work in Python, no matter if mystring contains only ASCII, or unicode letters, or emojis. It will work for any kind of a Unicode string. OTOH in C and Java, mystring[0] will work or not depending on what mystring contains: ASCII letters will work in all languages, diacritics like ąęśćó will work in some (majority?) of languages, and emojis will work only in a handful of languages. And this can be a reason why some tests in some languages might be considered irrelevant: if a Python solution works for ASCII-only strings, then it is very likely that it will work in similar way for other strings too. But it is not true for Java, or C. And this begs the question, if a Python solution works for ASCII strings, are tests for Unicode strings still needed?

What is your statement above based on?

the languages where codepoint indexing is directly handled by the language (Ruby, Python). in those languages, non-ASCII codepoints do not add any layer of complexity

Tests in these languages are needed not for complexity but for a unified structure in all translations following this rule from the translation recommendation

A translation should substantially change neither the overall idea nor the requirements of the kata. It should be as consistent as possible with the original version in terms of difficulty, required performance, and overall composition. In particular:

The fact that Dart uses a different encoding doesn't force the translator to add tests that don't exist in other languages. Each language has its own specifics that must be taken into account when translating, but if tests in another language work perfectly in your language, why complicate things by adding things that don't exist in the language you're translating from, violating the general form of Kata. Rules require adherence to a uniform syntax style if possible.

you have to take into account how strings work in every language. What is an edge case in one language is not necessarily in another. there are 3 types of languages:

• the UTF-8 languages (C, OCaml, Go, Rust, PHP, Lua...): strings are arrays of 8-bit code-units. what is needed is tests with all possible byte-wdith: 1 (i.e. ASCII), 2, 3, 4
• the UTF-16 languages (JavaScript, Dart, JVM-based languages (Java, Kotlin, Scala...), .NET-based languages (C#, F#...): strings are arrays of 16-bit code units. what is needed is tests with non-BMP codepoints, that take two code units to encode. since we want printable strings, these will be mostly emojis.
• the languages where codepoint indexing is directly handled by the language (Ruby, Python). in those languages, non-ASCII codepoints do not add any layer of complexity

The listed languages do not comply with the rule from the description:

Note: despite its name in some languages, your function should handle any Unicode codepoint:

1. Go has no Unicode tests
2. Factor has no Unicode tests
3. In JavaScript, Unicode is represented by a limited set of Braille
4. In Ruby, Unicode is represented by a limited set of Braille
5. In Rust, Unicode is represented by a limited set of Braille
6. In Python, Unicode is represented by a limited set of Braille
7. In Lua, Unicode is represented by a limited set of Braille, but there are several fixed tests with emoji

Some of these issues have been mentioned before, but they haven't been fixed, so I'm raising them again.
Most translations use Braille characters as Unicode tests. This is likely because the translations were done from Python and thus inherited its Unicode test suite. N stated below that the lack of random Unicode tests for Python isn't a big problem, but that's not true. Python is the most common language on CodeWars, and the likelihood that translations into other programming languages will be done from Python is very high, so the Python version should be flawless and serve as a kind of gold standard.

though the kata is indeed overranked, you solved it in Python, which is one of the very few languages where the string datatype directly handles codepoint retrieval and indexing transparently for the programmer. "exotic Unicode characters" do not make any noticeable difference in Python, whereas they do in languages where strings use UTF-16 or UTF-8.

Python is simple. You can get diabetes by programming in Python.

I expected more difficulty from level 5 kata, but it didn't live up to my expectations. The solution took less than a minute.
I think more exotic Unicode characters should have been added.