My platform is the Android command-line shell.  Essentially it is like an embedded linux platform with a very quirky partially implemented libc (not glibc).  It has no langinfo.h and while it has locale.h, the implementations of setlocale() and localeconv() do nothing (and return null).  The wcstombs() and mbstowcs() functions are both mapped to strncpy().

As was the original intent of utf-8, since the Linux kernel (and most supported file systems) store filenames as null-terminated byte strings, utf-8 encoded file names "work" with software that assumes that the encoding is utf-8 (for example the xterm program that I'm using to "ssh" into the machine) (for another example, the Dalvik JVM that runs user-apps.)

My intent with this tracker is to make it slightly easier for people who have libc like Android where the locale support is completely broken and really only 8-bit "ascii" is supported to get something reasonable to compile and run, while simultaneously not breaking the supported platforms.

If you look at what Kivy and Py4A have done, they basically have patches all over the main interpreter that, once applied, make the interpreter not work on any supported platform.  I'm trying to avoid that approach.  Two possibilities for this particular part of the interpreter are to implement option (3) above, or to implement option (4) above.  Option (3) is preferable in the long run, but option(4) is a much smaller change (as long as it does consistently with the decision of tracker 8610.)