There is a possibility of collisions in the future, we can use the reserved flags as a nonce for known collisions if this ever comes up.
This is a ticking time bomb. Good luck getting folks using this standard to implement this properly when this eventually happens. If this is the contingency for a collision, then a massive non-hash-based list of every combination was probably a better solution to begin with.
Edit: On second look, I'm not sure if binmoji is working properly? The component hash lookup table seems way too short to cover even a fraction of possible combinations, and it doesn't seem like it can properly roundtrip emojis such as this diverse family emoji: https://apps.timwhitlock.info/unicode/inspect?s=%F0%9F%91%A8...
Agreed. I feel that a lookup table can probably map all emojis possible to a uint32 (maybe optimistically uint16, [1] says there's about 4k emojis, does that include skin variations?). And you can add new ones sequentially after so IDs remain stable.
Comments
This is a ticking time bomb. Good luck getting folks using this standard to implement this properly when this eventually happens. If this is the contingency for a collision, then a massive non-hash-based list of every combination was probably a better solution to begin with.
Edit: On second look, I'm not sure if binmoji is working properly? The component hash lookup table seems way too short to cover even a fraction of possible combinations, and it doesn't seem like it can properly roundtrip emojis such as this diverse family emoji: https://apps.timwhitlock.info/unicode/inspect?s=%F0%9F%91%A8...
Agreed. I feel that a lookup table can probably map all emojis possible to a uint32 (maybe optimistically uint16, [1] says there's about 4k emojis, does that include skin variations?). And you can add new ones sequentially after so IDs remain stable.
[1] https://unicode.org/emoji/charts/emoji-counts.html
A nonce?