There are no checks which is a valid character but not ASCII.

Removed input validation altogether as per a suggestion on Discord.

random tests need to be adjusted, and null character needs to be specifically tested.

Updated the description to mention that characters can be unicode too, added a fixed test with just the null character, and random tests may now generate null characters.

what happens if emoji numbers like 069 or 007 appear in the input?

They're valid. Random tests now randomly precede ~1% of characters' strings with a 0 emote.

Also put the fixed/random tests into two separate blocks (suggested by saudiGuy) and doubled number of random tests.

Once you find out earlier research on the topic, it becomes clear. Puzzle tag seems acceptable here. Since various algorithms and solutions can be found online, this kata will not likely be approved at a difficult kyu level. Current ranking votes show this. I can approve at current average vote of 5 kyu, and probably should add a link to the wiki page describing this problem.

I changed the description a little bit, is it satisfactorily now ?

resolved

Should be fixed now.

It's why I have problems specifically with the tone of the description. It's not a "teaching kata". Just rewrite it and turn it into a puzzle or something.

The note has been removed. As I said, it was not meant to be a part of the final description, it was a kind of "inb4 'split-map-join is not a novel kata idea'" and I should have had probably put the info for first solvers/beta testers somewhere else.

I do not share your pessimistic vision of "they will just copy the thingies into the code", or maybe I hope that there will be at least one user who will go beyond this. "throwing random shite at someone" is the last thing I wanted to do, and if you perceive the task as such then, well, that's a pity and it was not the intention. There has to be some setting, some background, to not make the task sound totally artificial and "soulless", but maybe you are right, and the setting here is not the best one.

I also think this is not a good tutorial. Tutorial implies that I explain things (or at least I think so), but I do not want to explain them, I want users to research them.
At the same time, I think it is not a puzzle either. A puzzle would mean that some parts of specs are hidden and not available to users, but my intention here is everything to be controlled by unambiguous and clear rules, it's just that the rules are not given here.

I see it more like a "read the documentation" task, or "research an algorithm" task. Similar to "find a distance between two points" math task, or "create an extension method" or "parse/serialize XML" kind of a technical challenge.

Either way, tags "strings" and "unicode" should be added

Added.

Either way, tags "strings" and "unicode" should be added

That sounds more like "Puzzle". I think "Tutorials" is intended to be that the actual task is clear, but how to achieve it is guided/taught in some form, either in description or in initial solution. For example.

I don't think I would classify this kata as a tutorial.

The tag "Tutorials" exists for this purpose, I believe, where you want users to find out by examples what the underlying spec is.

Eww, this is some disgusting, detached from reality, borderline lying soft-talk, that looks like it's generated from GPT. If users are required to handle multi-byte sequences in a string in their code, this is not "educational" (even handling surrogate pairs and normalization is enough of a trap). "Wonders of Unicode", more like "Pitfalls of Unicode (handling)".

Okay, so the note worked, but not the way I intended :) I do not intend to keep this note in the description, I added it to make first beta-tester power-users aware that I see more value in it than a simple split-map-join task, and that my main goal is to make users explore the domain. The "wonders of Unicode" was meant to be tongue-in-cheek and sarcastic, but apparently I missed the 'WINKING FACE' emoji. Come on, we all know that there's nothing wonderful in Unicode, and working with it is difficult and full of pain, don't we? (btw I think that surrogate pairs are easy, but the Unicode normalization is very difficult, and totally out of place for this task and I am not even sure why you recalled it here as an example).

I should be more clear here and put the note in a first comment in the discourse, as I initially intended. I'm sorry for misleading you.

Also, can't you at least provide all the keycap digits somewhere, either in description or in preloaded? We really have to go look up multi-byte sequence characters ourselves? Again, in what way is this "educational" if you're casually making users handle multi-byte sequences without explaining the traps associating with them?

Of course I can provide the keycaps somewhere, but I did not want to. I do not explain the traps because I thought that the research the users take off to to figure out what keycaps are at all will be interesting experience. Just by looking up what keycaps are, the users will encounter things like emoji sequences (mentioned by you before), variant selectors, combining characters, etc. This is one of places where I see the learning value, especially for users who are familiar with some form of general coding, but not familiar with practical aspects and difficulties of Unicode. I do not want to provide a preloaded table of digit keycaps because, again, I think that not having them can result in some potentially interesting discoveries, like exposure to the concepts related to the Unicode, possibility/risks of clusters/sequences copy-pasted into code, or creating these with string escapes.

You made sure to_emojicode will only get emojis with a single codepoint, but keycap digit emojis are emoji sequences, so to_emojis with its current design will always take in a string mixed with whitespaces and multi-codepoint sequences, which is going against why to_emojicode doesn't take multi-codepoint emojis in the first place. All current solutions are hard-coding their to_emojis to specifically handle only the 10 keycap digit Unicode sequences in fragile ways, which not really "educational" as your description has touted for such a "supposedly simple" kata.

I am sorry but I am afraid I do not understand this part. I agree that handling of Unicode sequences can be problematic in general, but I thought that this difficulty will be alleviated by the fact that emojicode has a well-defined, simple format. It is always triples of codepoints separated with spaces. I hoped this will take away the difficulties of working with generalized unicode sequences. I also wanted to have some to_emoji part in the challenge, because I wanted to force the users to do ((codepoint - 0x10000) >> 10) + HIGH_SURROGAGTE. It turned out
to be not necessary for Python, but I would like to have it in some other language, or maybe at least some users will use it in their solution for whatever reason. That's why I want to have some codepoint-to-emoji conversion part in the challenge, but yes, the input codepoint does not necessarily have to be expressed as emojicode. But again, I believe that by ensuring a simple structure of the emojicode, amount of problems would be significantly reduced. I can be wrong tho and miss something. I would like you to elaborate on the "fragile" part, if you don't mind. I want to learn too! :)

Thanks, didn't realise it was already up

specified