Sure, but it was painful. Very painful. It's not quite that painful
for std::optional, because it's not used elsewhere in the library
internals.
But still, it's painful.
It wasn't painful for me - I barely noticed it. Of course, everyone's mileage varies.
In my opinion, in these days of containers, it's much easier to support multiple ABIs.
I don't think everybody uses containers.
I don't think the Standard should concern itself with ABIs. It should promote source compatibility. It should be up to the vendors to decide whether to race ahead or be conservative.
I think the standard should concern itself with how the things
specified in it can be deployed.
The Standard should not make decisions that cannot be implemented. But it also should not refrain from making decisions that cannot be implemented optimally on every platform, and instead leave it to the platform to make a choice.
Distribution vendors already rebuild all their packages for each major release, and third-party vendors already build for multiple architectures. Having them build for the most recent and next-recent ABI is annoying, but not more than that.
You're talking about doubling the amount of ABIs a vendor needs to
target. That's a non-trivial exercise.
It is not a trivial exercise. But are we not dooming the language if we freeze some features to a set of decisions made some time in the 90's?