You can continue working in a world without the small string optimization if you want. There is already precedent.

I want a world where the compiler knows when it can use that optimization instead of me bludgeoning it with a global define.

Like you said, it's not even that far fetched.

It’s a library feature not as compiler feature so you can’t really get out of telling the compiler which library to use, Eben if what you say is nothing (meaning “default library”)

Maintaining a C layer is standard practice for many libraries because that enables their use from a variety of programming languages. Consequently, the tooling around that is quite mature.

Sure, but if C++ had a stable ABI, then it would be more practical to directly wrap it. SWIG has some support for C++, after all, and there are a lot of C++ wrappers (e.g. ROOT, pybind11 and Boost.Python can all automagically generate python bindings for C++), but guess what happens when you mix libraries compiled with different std::basic_string ABIs...

It has two on Windows, they are called COM and UWP, although technically it is just one as UWP is an evolution from COM.

It has has one on IBM i and z/OS, as part of the language environments.

C++ has the stable Itanium ABI too, but that doesn't help when needing to bind with code that uses templates or preprocessor macros since those features are inherently language dependent. That's why re-wrapping the code with a C-compatible ABI is often a better approach. COM can also be accessed from C, by the way.

COM can be used by C if you are a masochist and feel like doing COM "Assembly" programming without some of the compiler hand holding, it got even worse with UWP that uses .NET metadata files, with support for a .NET like type system.

I guess when one is bored might try to re-implement ATL, WTL or UWP projections with C macros.