I put together an implementation of the same basic idea (for Smalltalk -- where
the absence of static typing allows such things to work a lot better).

There's a separation between the interface to my strings (which are
intersubstituable with the implementation's built-in String class), and their
physical representation.  One of the physical classes represents its data as an
internal Array of UnicodeCharacters (this is mainly meant as a
simple-as-possible implementation for sanity checking and unit tests).  Most of
the other implementations keep their data as a ByteArray internally and use one
or another UnicodeByteEncoding to interpret it.  There are encoding for
UTF-8/16/32, plus the obvious-but-doesn't-actually-exist "UTF-24", and Java's
wierd encoding.

One of the features I plan, but haven't got around to implementing yet, is for
the variable-width encoded strings to keep a record of the first "glitch" in
the encoding -- the first position where there's a character which doesn't fit
in the encoding's minimum width.  That should (I hope) mean that UTF-8 can be
used efficiently in space /and/ time for data which is predominantly ASCII.

Writing about it here reminds me that I really ought to get that stuff
finished...

   -- chris

that makes sense. Internally they could all be treated as the same
type to the programmer.  

You could do it like this:

A string literal could have a two bits marker

00 stored as 8-bits per char NO MULTICHAR STRINGS Unicode 0..FF
(greater range that UTF single char)

01 stored as 16-bits per char no multichars

10 stored as 32-bits per char no multichars.

A string  than has many possible internal and hidden representations:

It would even be possible for a string to be a list of the calls to
append that created it, an array of a hodge podge of the three sizes.

The String class would be at liberty to reorganise Strings, collapsing
pieces, making them all one piece of the largest size, or splitting
them to isolate just a few difficult characters leaving the rest in
narrower strings.

This sounds horribly complicated, but even a newbie could implement
such a string class. It is just a lot of bookkeeping. It the cases
where a string has a single segment, the code is almost as fast as the
code we use today, and it would actually use LESS RAM, since so many
strings are in made completely of characters in the rang 0..FF.

The difficult part comes in optimising. When to split, when to join.
Actually splitting and joining are trivial.

Any JVM maker or AOT maker could implement his idea today with 16-8
bit Strings and you would never know unless you peaked inside. The big
payoff for mixed width strings internally  would come if Java started
using 32-bit Strings as the default.

Similarly optimisers might internally use arrays if byte or int
instead of long when the optimiser determines that in actuality that
suffices.  

 One might use:

final java.lang.String chString = string.substring( n - 1, n );
final int ch = java.lang.Character.codePointAt( chString, 0 );