I spoke to several Japanese OpenBSD developers about this. They told me UTF-8 is not perfect but it's the least of available evils. They'd be more happy with a UTF-8 capable base system than with the current state of things where with few exceptions UTF-8 is supported only by 3rd party applications installed from ports.
And note that this is about system locales which mostly concerns libc APIs. Applications are still free to support additional character sets via other means (e.g. iconv).
For some problems a locale may not be the best answer.
For instance, during these conversations I learned that Japanese android phones expose filenames as Shift-JIS which cannot be listed by ls(1) when the phone's filesystem is mounted in OpenBSD. In my opinion what's needed is not a system locale that switches everything to Shift-JIS but a translation layer which presents filenames as UTF-8 to the rest of the system. Perhaps a fuse filesystem module which links to libiconv in userspace to perform the necessary translation, and presents the result at an auxiliary mount point.
And note that this is about system locales which mostly concerns libc APIs. Applications are still free to support additional character sets via other means (e.g. iconv).
For some problems a locale may not be the best answer. For instance, during these conversations I learned that Japanese android phones expose filenames as Shift-JIS which cannot be listed by ls(1) when the phone's filesystem is mounted in OpenBSD. In my opinion what's needed is not a system locale that switches everything to Shift-JIS but a translation layer which presents filenames as UTF-8 to the rest of the system. Perhaps a fuse filesystem module which links to libiconv in userspace to perform the necessary translation, and presents the result at an auxiliary mount point.