> Only in a very shallow sense, though. If I switch msvc build mode from release to debug, sizeof (std::string) changes from 32 bytes to 40 bytes. I also had to get two 3rd-party manufacturers to upgrade their compilers (from msvc2010 to msvc2017, IIRC) because they were using std::strings in their public interface, and their std::strings were not the same as mine.

And I get it. I have been there. I had to deal with this sort of problem over and over again.
You have a vendor that only gives you binaries and just sends out their C++ interfaces and they don't even realize that it is a problem, because it works for them and their tools, and they couldn't convince anyone else using a different compiler (that is not at least 15 years old) and that this would be a problem.
Annoying as it is that you are almost practically forced to use their preferred tools instead of the ones you have been developing your product in up until now, that will only get you so far as the next vendor comes along and does something completely different, you can't even combine both components on the same application no matter your best efforts to be accommodating.

The problem here is, to put it bluntly, there are a lot of companies who are just outright incompetent at designing interfaces.
std::stable wouldn't fix this, if a vendor doesn't know that C++ interfaces are not portable across compilers, and is incapable of building an interface that actually works, they probably wouldn't be competent either to use std::stable::string instead of the plain old unportable std::string.
It won't fix the problem you have now, it won't stop the problem from happening again and again in the future.

You got to know the target audience. Companies who do know how to make interfaces will either give you source code to compile it yourself, or they meticulously customize their interface types so that this is not a problem.

Developers who understand how to design a binary interface will not need std::stable, and developers who don't know it will not use it.

The only thing that it would do in practice is to create a burden, a burden to the committee to properly define these things, a burden to library implementers to maintain and ship std::stable versions of things, and almost no one of interest will use it.


This type of "interoperability" it is partially an issue of binary management "which is outside of the C++ standard" (and it is up to implementers to provide a solution for), and to the extent that standardizing something for is relevant it ain't going to happen. The issues as to why C++ isn't a good for cross-binary interfaces have been there since the inception of C++, it is intentionally wishy-washy on the details. Changing that would require making radical changes to the language to the point that it would not longer be recognizable as C++.

As well intended as it might be, it won't actually solve any problem, it will just create more problems.