Hi all I was wondering what limitations will we have if Unicode had decided to assign one and only one codepoint to every user-perceived character?

Currently, Unicode has code-points that correspond to combining characters.  Such characters combine with a previous code-point (or sequence thereof) to present to the user what appears to be a single character.

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.

For example, in Unicode when a grapheme cluster is represented internally by a character sequence consisting of base character + accent, then when the user clicks the <kbd>></kbd> button to skip to the next user-perceived character, we had to skip from the start of the base character to the end of the last character of the cluster.

Why does it need to be so hard? Why can't we assign a single code point to every user perceived character such going to the user-perceived character is simply a matter of reading the next code point?


The [unicode website][3] seems to acknowledge this complexity, (although I could not understand what exactly is so rare about having to figure out the number of user-perceived character counts in a string):

> In those **relatively rare circumstances where programmers need to
> supply end users with user-perceived character counts**, the counts
> should correspond to the number of segments delimited by grapheme
> clusters. Grapheme clusters may also be used in searching and matching


Diacritics are also the reason why things don't work as expected. For example, if I throw 2 ピ characters (japanese katakana PI using the unicode representation `U+30d2 U+309a`) into a [String builder][1] and reverse it, I would naturally expect the output to be 2 ピ characters (i.e. ピピ), but it gives an invalid output of ゚ピヒ ! 

**If Unicode had assigned individual code points for each user-perceived character and scraped the idea of grapheme clusters, this wouldn't have happened at all.**

What I would like to know is, what exactly is wrong with representing every user-perceived character as one unicode codepoint? Is it likely that doing so would would exceed U+10FFFF possible code points (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), Even when there is so much spare space to include the whole family of [Elf Languages][2] ?





  [1]: http://docs.oracle.com/javase/7/docs/api/java/lang/StringBuilder.html#reverse%28%29
  [2]: http://en.wikipedia.org/wiki/Quenya
  [3]: http://unicode.org/reports/tr29/#Grapheme_Cluster_Boundaries
  [4]: http://blogs.msdn.com/b/michkap/archive/2007/05/09/2497106.aspx