So, back in 2009, Andreas proposed:---------------------------What I would propose to do here is to define that "leadingChar = 0" which currently means "Latin1 encoding, language neutral" is being redefined to "Unicode encoding, language neutral". What this does is that "Character value: 353" and "Unicode value: 353" become the same, if the environment is considered language neutral which by default it would be.---------------------In 2010, he pushed this into Squeak Trunk.Then, in 2011, there was a conversation where Andreas stated:-------------------On 1/8/2011 2:16 AM, Sean P. DeNigris wrote:#leadingChar"In Squeak Character encoding, bits above 16r3FFFFF don't encode thecharacter, but hold information about the language environment and theencoding which should be used to interpret the charCode. The background ofwhich is Han unification (http://en.wikipedia.org/wiki/Han_unification) ."How's that as a method comment? Is it really "In Squeak... encoding..." ordoes this apply to unicode in general?It is Squeak specific. Unicode does not have a leading char.Cheers,- Andreas---------------------Maybe this later email was the one that you were interested in?I can't find any mention in the commit list or other discussions where the leadingChar was dropped, but I'm not an expert in this space (just interested).Thanks,cbc