IMHO, it's not an issue of implementation. It's an issue of design. If PG explicitly says "ok, I don't have time to do Unicode stuff now, but my idea is that

IMHO, it's not an issue of implementation. It's an issue of design. If PG explicitly says "ok, I don't have time to do Unicode stuff now, but my idea is that a string is a sequence of characters, regardless of how a 'character' is represented", then somebody can go ahead to change Arc Unicode-clean (it won't be much work assuming MzScheme has support of Unicode). If PG says "the language Arc (not mere an implementation) doesn't support beyond Ascii", then I feel that PG reserves that part of design (e.g. it may conflate byte-array and multibyte strings, or it may use richer character representation than unicode codepoint, such as a character object that holds the sequence of base char + modifiers, or it may hold raw byte array plus encoding info). In that case I hesitate to change Arc code without understanding PG's intention.