Thaddy, I posted about a realistic improvement to current units of Lazarus (utf8) users: Just insert a directive {$modeswitch utf8strings}in your existing units, that's all. By this you have no hack via ACP runtime-change anymore.
You might still need it, since already compiled units (including FCL and things like TComponent and TStrings) are defined with the old string definition, since these units are compiled without that modeswitch.
Sad as the UTF8 ACS hack is, it at least fixes that.
Marco prefers {$modeswitch unicodestrings}, because he prefers utf16 over utf8.
For the long term I prefer delphi compatibility over a make-it-up-as-you-go adventure, that only strains dual maintained codebases. Making features simply Delphi compatibility also kills a lot of discussion and embellishment.
Fixing a problem is simple, what-does-delphi-do, and the direction is clear the same day. It doesn't lead to maillist discussion with several hundred mails without conclusion.
Also I think there is a lot of ill-advised spin, where the advantages of UTF8 as a web and document format are hopeless mixed up with having UTF8 as a base string type. Most of the people writing about it don't even fundamentally understand both Windows encoding and the string type system of FPC and Delphi.
In this unit, Lazarus users must port their old (String = acpUtf8) code, having two options (utf16 or utf8):
a) keep "String", but ensure (possibly modify) the related code still works with utf16 instead of utf8
b) rename "String" to "Utf8String"
Old unclean code is toast with every which way you go. People had to make modifications from the old UTF8 hack to the new one. Really clean code is surprisingly encoding independent.
This is an improvement over the current status, but the question is, how long (for Lazarus devs and users) is the transition phase to (String = utf16) and how many will participate.
Well that is the core problem. The utf8 hack was presented as a transition horse but kills all motivation to make haste, or to even allow people to start major development if it is doubtful if it will be accepted back.
My proposal (extension) was for the many users which want to keep their Utf8 decision with typename "String" (here Utf8String internally).
And that is what the UTF8 hack also does, so the additional value is doubtful.
To resume, in the long term, we have only three "String" options:
A) stay with old (String = AnsiString = acpUtf8) hack
B) use my (String = Utf8String) extension
C) use String (utf16) and Utf8String
The official course to my best knowledge is long term (C) temporary (A).
If option B is used and Delphi compatibility required at a later stage,
then the user can opt for a search-and-replace (String by Utf8String (or customname)).
It doesn't work that way. Any assignment now becomes a conversion and thus dependent on ACS. Also what you conveniently skipped to comment on is that the implementation of such feature is more than a simple option to alias the type.
IF the STRING is 1 byte, currently the mother type for conversion is the string(0) (aka ACS). Changing the definition of string does not change that.
Your proposal is not thoroughly researched. The best way to find out if something is doable is to start to implement it, discover problems, fix them, and then present your work.