Andreas,

  Good summary.

> a) All references to String, AbstractString and MultiString need to be 
> checked to see if they will be okay to remain the way they are. This is 
> a daunting task - in a full 3.8 image there are roughly 850 references 
> to String alone.

  I've done that several times for 2.4, 2.8 3.0, 3.2, 3.6 and 3.8, but
it just got harder to keep up...

> b) It seems there is quite some confusion in AbstractString, String, and 
> MultiString as far as the protocols are concerned. For example, consider 
>   the duplication of the comparison protocol - clearly that isn't 
> needed. Some parts are outright broken such as 
> AbstractString>>indexOf:startingAt: which will fail for multi byte 
> strings (it always uses the ByteString version).

  Guilty as charged.  The basic strategy is somewhat confused, since
the way the methods are "lifed" up to AbstractString from the old
String, sometimes the implementation at AbstractString is used, but in
some other cases, it is declared as subclassResponsibility and the
subclasses define the method.

  Clearing it up so that using #subclassResponsibility would be good,
I think.

> Possible plan of action: As far as I can see from looking over the 
> changes a plan of action does need to address the above three issues 
> (and some that I haven't seen yet). It requires:
>
> ...
> 

  After these steps, we should replace all the #== equality check for
characters with #= for the similar reason as Numbers.

-- Yoshiki