The committee won't change something if the change would break the ABI of one of the big implementations. It's not a formalised ABI stability promise, it's just a result of implementers having veto power and wanting to keep their implementation's ABI stable.
While the C++ standard does not define any ABI, some implementations (namely GCC and clang) put a lot of effort into maintaining reasonable ABI compatibility. GCC has only changed ABI twice (afaik) and the second time the only thing that changed was std::string!
Nowadays MSVC tries to maintain ABI compatibility too, so we should stop seeing a proliferation of those msvcrXXX dlls.
Haiku uses C++ for its OS ABI so it relies quite heavily on the fact that ABI compatibility stays very consistent across compiler versions for example.
Same applies to Rust, with the difference that there isn't a story for shipping binary libraries, that is why OSes like Haiku care about keeping the ABI consistent, those BeOS applications aren't going to be recompiled.
Instead of breaking ABI compat for `unordered_map` why not define a new type given that it's so different? It can even be called the same thing and just exposed through a different namespace version (something that's been supported for a while). About the only thing real is intmax_t. The rest feel resolvable within a library without changing ABI / breaking back compat.
As anyone who has looked at disassembled C++ code can attest, "C++ is performance first at any price" aka "zero-cost abstraction" is mostly a pipe dream. Whatever sufficiently smart compiler was meant to make it happen has not materialized.
I don't think thats correct.. C++ has UB because of backwards compatibility, which has origins to design choices of C in the 70s. Its not like it is optimized for performance above all else, it had immediate needs to be close to metal, and that is the best they could do back then, there was not some "strongly typed" versus "performance" debate happening at the time.
The creator of C++ would love for there to be safer abstractions, but has the baggage of the past to carry.
C++ is performance first at any price. Hence UB.
Rust is also after performance, but will specify implementation details where C++ will defer to compiler writers.