On Monday, 19 September 2022 19:22:05 PDT William Linkmeyer via Std-Proposals
wrote:
> For example, how the `std::string` fiasco could have been avoided if the
> standard’s compatibility range, supplied by the author, was embedded within
> the binary.

It was embedded in the binary in another way and was selectable by the user.
It still is. See:
https://abi.godbolt.org/z/ref4xs9M7

It's just non-standard because it only affected one implementation.

The fiasco happened because there was an implicit change to what "std::string"
meant, because of the use of an inline namespace:

If every type and class is always referred to by their full name, then no
problem exists. And if you remove the ability to change the ABI or behaviour
in a class, then the only way to achieve a similar objective is to duplicate
the type in question change there, making everything opt-in.

In that light,

using std = std::v<2017, 2023>;

Is fine. Remembering, of course, that that library headers must never add
"using namespace" or make namespace aliases in their headers. That would mean
everyone must write the full name... which is SOURCE incompatible compared to
today, where you can write std::something.

-- 
Thiago Macieira - thiago (AT) macieira.info - thiago (AT) kde.org
   Software Architect - Intel DCAI Cloud Engineering