> You could equally say that new emojis shouldn't be added because you should use inline images for those. If emojis weren't allocated out of compatibility con

> You could equally say that new emojis shouldn't be added because you should use inline images for those. If emojis weren't allocated out of compatibility concern, this would be exactly my opinion from the day 1. To be honest I'm not still happy with the current emoji assignments and semantics. Not even Unicode people are satisfied either, there are numerous proposals for replacing emoji with something else (example keyword: QID emoji). > RTL markers shouldn't be added because you should use dedicated text styling for that. > There are a ton of places that don't support superscript markup. Unlike most text attributes, bidirectionality is an intrinsic property of abstract characters and thus absolutely within the Unicode's scope. Ideally you can't and shouldn't make some LTR character to behave like RTL characters or vice versa. Bidi control characters only exist to correct automatic rendering, and can be presented out of band (the Bidi specification is explicitly designed for this use case in mind [1]). [1] https://www.unicode.org/reports/tr9/#Markup_And_Formatting https://www.unicode.org/reports/tr9/#Markup_And_Formatting