I think almost everything you said relies on seeing the old ways through rosy glasses and massively underestimating the daily problems that the multitude (techn

I think almost everything you said relies on seeing the old ways through rosy glasses and massively underestimating the daily problems that the multitude (technically, gazillions) of encoding standards and standards on how to encode encoding choices brought to the many people who already worked regularly with computers in the early 90s and before that. I'll just pick a single point I disagree with, and then comment on the one point that to me has true merit. So you write, You can do a lot in HTML because HTML has a lot of specific support - something that would likely also be true in a world without unicode. (In the unicode world we have only one encoding per HTML file, but there's no reason a file format couldn't support multiple encodings in the same way as supporting multiple language spans etc.). Basically you reject a format—HTML+Unicode—that has seen tremendous global acceptance, that has brought us 'rich text' (to quote Microsoft), near-complete universal language support for hundreds of previously entirely unencoded writing systems, ability to display ruby text (i.e. small annotations, parallel version of text; btw. not limited to Japanese at all) and want to replace that with 'a file format [that] support[s] multiple encodings'. I agree that it would sometimes be nice (i.e. nice-to-have) inline encoding switches in HTML. You could totally write a JS method to do exactly that, right now, so go ahead! But to replace HTML+Unicode with 'some unspecified file formats' that 'could have' multiple encodings in a single file? Doesn't sound like I want to go down that particular cul de sac. OK now on to that other point: you write your file format has to go beyond "plain" text for the most basic functionality of properly displaying [some features for some linguistic situations], if I may be so bold and generalize to avoid that fixation on "boo it's Japanese again and only Japanese that has been put at a disadvantage". So where I agree with you is that historically the Unicode consortium was too reluctant to acknowledge responsibility for some features of written text that should be expressible in the very text, not in a 'side channel' (e.g. in HTML tags). This would IMO include markers for start and end of stretches of a language, so you could write "good day, {lang=fr}Messieur{/lang}" where the curlies symbolize where Unicode control character sequences (not unlike those already used for flags) should appear. There's more stuff like that like e.g. indicating position of text relative to other text; we sort of have it in the form of CJK Ideographic Description Characters and Control Character for Ancient Egyptian, but nothing for the general purpose.