[Arnavion]

>if we were to program in Hindi, the very shape of our characters would depend of the context...

Eh? What context-dependent-shape-changing are you referring to? Hindi has a very normal alphabet. There are vowels, consonants, and a bunch of special ligatures for some combinations of those that are technically optional and could be done without. Nothing changes according to "context".

[shakow]

> are technically optional and could be done without

My bad, I thought those were mandatory.

[Arnavion]

Even if they were mandatory, they're just ligatures. There's no context about them.

[shakow]

The very concept of a ligature is to alter the letter depending on its surrounding context.

[Arnavion]

Okay, guess we disagree about what "context" means.

You can't write adam, you have to write Adam. This is because the letters don't carry enough information; you need to know the context that names are capitalized, which is information that is extrinsic to the text itself.

Similarly, you can't render a unified Han glyph without knowing the context of which language the text is in. This information is again extrinsic to the text itself - it is metadata about the text.

In comparison, when you can't write Hindi ru as r and u as you usually would but instead you have to write the letter ru as its own glyph, there is no extrinsic information needed. The letters are right there, so all the information for knowing how to render the letters is right there. There is no context needed.

But yes, if you define context to include surrounding letters, then yes you need "context" to render Hindi letters. But since the original context of this was the difficulty of supporting this context for programming identifiers, I'd say that this kind of "adjacent codepoints context" would not be something special to worry about anyway, because text renderers today already have to deal with this kind of "adjacent codepoints context" for emojis, etc.