What limitations will we have if Unicode standards 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. (We're **not** talking about  [ encoding issue][1] here.  Even if we try to avoid any kind of complexities by using an encoding like UTF-32, the **problem still persists**.)  

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 Unicode 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][2] seems to acknowledge this complexity:

> In those **relatively rare** [not rare at all!] **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][3] 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 scrapped 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][4] ?

[Unicode states][5]:

> If you wanted, for example, to give each “instance of a character on paper throughout history” its own code, you might need trillions or quadrillions of such codes; 

But seriously that doesn't make sense at all. Where is the source for making such a claim? A trillion codes is quite an over-statement.


  [1]: https://softwareengineering.stackexchange.com/q/102205/24257
  [2]: http://unicode.org/reports/tr29/#Grapheme_Cluster_Boundaries
  [3]: http://docs.oracle.com/javase/7/docs/api/java/lang/StringBuilder.html#reverse%28%29
  [4]: http://en.wikipedia.org/wiki/Quenya
  [5]: http://unicode.org/faq/utf_bom.html