Как я понимаю, если избрать Utf8 или Utf16, то мы расплачиваемся сложностью алгоритмов, поскольку литеры кодируются переменным числом байт. Элементарное LEN(str$) становится неэлементарным.

А если избрать Utf32, то расплачиваемся размером памяти: для большинства модульных текстов вообще 3/4 памяти - нули, для русскоязычных - половина. Однако выигрываем в простоте алгоритмов, и вообще прозрачности понятий: один CHAR  - это именно одна литера, как и подразумевает название, а не половина, не треть и не четверть, в зависимости от того, что было до нее.

Я очень ценю память, и хвастаюсь низким памятепотреблением ББ; но когда на чашах весов прозрачность и простота, с одной стороны, а с другой - удвоение памятепотребления (с 2-4МБ до 4-8МБ, в моих сценариях использования) - я выбираю терять мегабайты и сохранять простоту и прозрачность. Иван Андреич, а в близких к аппаратуре применениях это, наэн, существенно - столько байтов терять?..

Я тоже думал про тип LONGCHAR (возможно - SYSTEM.LONGCHAR, чтобы, например, поэкспериментировать в "песочнице"). Тогда, выходит, будет в языке уже три вида литер и три вида строк.
Любопытно, насколько "совместимы" UCS2 и UTF32: т.е. если приставить "старшие нули" к UCS2 коду литеры, то получится ли валидный UTF32 код той же самой литеры? (Это работает от ASCII к UCS2, что позволяет иметь элементарную реализацию LONG(sstr)/SHORT(str))

А еще, можно же, например, в языке (и, знач, в памяти ЭВМ) использовать UTF32, а при экстернализации по умолчанию (т.е. в Stores.Writer.WriteString/Stores.Reader.ReadString) переходить на UTF8, или как-то иначе упаковывать строки.