Fundamental problem with grapheme clusters as a basic programming language concept is that they are not uniformly defined, they depend on grapheme_extend proper

Fundamental problem with grapheme clusters as a basic programming language concept is that they are not uniformly defined, they depend on grapheme_extend property of unicode characters, which are known only for already defined codepoints. Which means that such splitting is problematic to be done in forward-compatible manner. It is also costly and in many cases not necessary. Which makes it more suitable to be provided by a library than to be a core language concept. Secondary issue is that with codepoints (or bytes) as basic concept one can compose grapheme clusters in the same manner as general text composing, while if grapheme clusters are basic concept then one needs specialized operation for composing them from codepoints. OTOH, pretty much agree that O(1) access to code point is not important and keeping internal representation in UTF-8 (or in input encoding) is OK for most purposes.