As origens da Unicode remontam a 1987-1988, quando Joseph D. Becker publicou a primeira proposta preliminar Unicode . Uma codificação de largura fixa de 16 bits (UCS-2) era uma parte indispensável de seu design. Ele estava muito orgulhoso da distinção que ele fez entre caracteres e glifos, apenas para espremer tudo para esse pequeno intervalo. Infelizmente suas hipóteses ingênuas foram provadas erradas, ou pelo menos irrealistas, quando em 1996 o espaço de código Unicode foi aumentado além do limite de 16 bits e o UCS-2 foi estendido para UTF-16. Atualmente, o Unicode tem quase o dobro de pontos de código alocados do que o espaço de código do design original de Becker.
[...] if it does exceed U+10FFFF code points I see no reason why they couldn't have set the limit to 2^32 in the first place [...]
Atualmente é limitado por U + 10FFFF, porque é o máximo alcance possível de ser codificado com UTF-16. O UTF-16 é um hack feio aplicado no final do dia para estender o espaço de código. Não é extensível. UTF-8, por outro lado é. Originalmente, o UTF-8 permitia codificar 2 31 codepoints e, posteriormente, limitou-se a apenas corresponder ao mesmo intervalo que o UTF-16. Na verdade, você pode estender indefinidamente o esquema usado pelo UTF-8, até mesmo codificar 2 128 codepoints e preservar todas as boas propriedades do UTF-8 ao mesmo tempo (correspondência de substring não ambígua lexicograficamente comparável com UTF-8). -8 código inconsciente, etc ...) exceto que você não será capaz de determinar o tamanho do codepoint do primeiro byte.
From what I can see, the current standard is full of complexities. Even if I try to avoid any kind of complexities by using an encoding like UTF-32, this problem still persists. It's not an encoding issue at all.
Exatamente! Gostaria de salientar que as codificações de tamanho variável não são o problema . De fato, encontrar o próximo ponto de código em uma string UTF-8 é simples, basta procurar pelo próximo byte do formulário 0xxxxxxx
ou 11xxxxxx
. Assim, poderíamos facilmente aumentar o espaço de código disponível sem aumentar o consumo médio de memória. O problema real é que, para encontrar o próximo grafema, você deve ter um banco de dados Unicode disponível (de alguma forma), que é definitivamente complexo e caro para muitas aplicações simples.