To be honest, I think this approach to working with emojis is very flawed. It seems to be most obvious on Slack, where multi-component emojis are regularly spli

To be honest, I think this approach to working with emojis is very flawed. It seems to be most obvious on Slack, where multi-component emojis are regularly split into separate characters. Case in point: {"emoji": "‍‍‍", "name": "family_mothers_two_girls", "shortname": "", "unicode": "", "html": "‍‍‍", "category": "p", "order": ""}, This should really not be `family_mothers_two_girls`, nor should it be "Family: Woman, Woman, Girl, Girl" as Emojipedia describes it (https://emojipedia.org/family-woman-woman-girl-girl/ https://emojipedia.org/family-woman-woman-girl-girl/). It should be (and is, in the underlying unicode) `woman,woman,girl,girl` - the zero width joiners being represented as commas. On Slack, when I post the "Man Singer, Medium-Light Skin Tone" (https://emojipedia.org/male-singer-type-3/ https://emojipedia.org/male-singer-type-3/) emoji, it splits it up into a man with medium-light skin tone, followed by a microphone. This is because it has replaced my emoji with: :man::skin-tone-3:‍:microphone: What Slack should be doing is storing my emoji as: :man,skin-tone-3,microphone: This differentiates between zero-width-joined emojis, and multiple separate emojis. Currently there is no difference, and there is ambiguity about what my intent was - currently it just has to guess about which might want to be joined. Of course this also means that Slack doesn't just work with new emojis or newly combined emojis - they all have to be added and supported manually. That defeats the entire point of the emoji standard! Instead of storing labelled versions of the emojis, why not just consider storing the actual unicode code points...?