Indeed, it's entirely feasible to offer support for locale or other internationalization (i18n) features without making them mandatory; they should always be optional features that users can opt out of.

Additionally, it's worth noting that the standard std::locale functionality has faced challenges in practice. For example, in some cases, libraries like libstdc++ may encounter crashes when users attempt to set a locale, and the naming conventions for locales are not standardized across platforms, particularly because Microsoft does not adhere to WG4 standards.

As I mentioned, there is a viable alternative: providing a unified API that handles both strings and streams, which could also be compatible with third-party libraries such as Qt. It's essential to recognize that concerns regarding these issues can be effectively addressed by leveraging libraries like my fast_io library.