I believe this to be a poor idea, scripts should always remain
portable. I have no problem with only supporting UTF-8 encodings,
though others who still use neither that nor ascii might.
It also looks as if your patch may have some irrelevant changes
included, that are not inside the HANDLE_MULTIBYTE blocks.
Building in a table of chars which are acceptable like that looks
like a very poor solution to me - the unicode people keep adding
new characters, and whole new code planes (for additional languages).
Deciding now, to apply forever, what is to be acceptable and what
is not, once stepping outside simple ascii, seems like a very poor idea.
Beyond that, for fun, I had a look at your tables in the Thai section,
(\u0E00 .. \u0E7F, though not all of those are used) and what's there
looks to be nonsense to me. While lots of character combinations make
no sense as Thai words, so do lots of ascii combinations of characters
make no sense as English (or any other language) words - but we still
allow them to be variable names, despite being nonsense as words.
I'm actually not sure why, if non-ascii var names were to be allowed,
there needs to be any restriction at all on what (non-ascii) characters
would be used for them - the only reason the restrictions are needed for
ascii, is that lots of the ascii code points are used for other purposes,
so if (for example) ':' was allowed in a var name, would ${foo:-} be
testing $foo for unset or empty, or $foo: for unset? There are a zillion
little things like that which require that (ascii) names have a restricted
character set (same with not starting with a digit, that's so $1bar continues
to mean ${1}bar and not ${1bar}.)
But there's no such reason for non-ascii, if they're allowed at all, they
might just as well all be allowed (even things like non-breaking space,
and zero-width space, and stuff like that) as they're not sh syntax either.
Doing that means that you get rid of the tables completely, and any code
point (except the idiotic surrogates) which is correctly encoded, from
0x80 up to 0x10ffff would be OK, currently assigned to a glpyh or not.
People could use emoji's as variable names!
kre
