After all, there is UTF-7, UTF-8, UTF-16 (Big and Little Endian versions), UTF-32 (Big and Little Endian versions) and UCS-2 (UTF-16 is basically the same from what I've read over the past couple of days, though UTF-16 allows for the characters outside of the BMP)...
.NET and FB both deal with Little Endian only (though with .NET it is more of a preference rather than a requirement), so perhaps that is an option for QB64 should Unicode be implemented.
Regarding the idea of having a single ASC function, that is implemented in FB via the combination of the -lang switch and preprocessor definitions resulting from that switch. If Galleon were to create a function acting similar to ASC for Unicode, there are two options that I can think of at the moment:
1) Use two functions, where ASC is for the QB dialect and _ASC or _ASC64 or something like that would support both ASCII and Unicode
2) Use a single function, and add something like the -lang switch.
As for CHRW$, it is a good idea if Unicode is implemented. I believe Galleon has stated that extensions to the QB language are added by prepending underscores to the names, like _INTEGER64 for example, to avoid clashing with QB variable names, procedures, and so on in existing QB programs.
Waiting patiently for Windows 7, XHTML 2.0, CSS 3.0, PHP 6.0, the ratification of C++0x, and the day that I can code without logic troubles.