These things come with a performance cost and constraints on how the language can evolve.
I would argue that C++ needs to increase the pace of change if it wants to remain relevant. Rust, Go, Swift and Kotlin are though competition, while C++20 is still lacking in agility, safety and modularity.
What's more modular and agile than being able to link another library you didn't compile yourself without worrying about your language version or compiler?
C++ build systems are already worse than all the languages you mentioned in part because there's no module support.
I also disagree that it would hurt performance. If the logic contained in "-D_GLIBCXX_USE_CXX11_ABI=0" was formalized to allow backwards compatibility, libraries would snap together more easily while still preserving inlining better than C ABI exports are able to.
> What's more modular and agile than being able to link another library you didn't compile yourself without worrying about your language version or compiler?
The point of the document is to lay out the goals and priorities of the authors, not to argue that they are universally applicable. The authors compile everything from scratch with the same version of the compiler, down to the OS kernel.
> Rust, Go, Swift and Kotlin are though[sic] competition, while C++20 is still lacking in agility, safety and modularity.
What is the point of fighting to stay relevant by going after use cases that are being served by these other languages? Is it just to win and have more "mind share"? Is it to make the biggest tribe? That seems like a social goal, not a technical one.
I would argue that C++ needs to increase the pace of change if it wants to remain relevant. Rust, Go, Swift and Kotlin are though competition, while C++20 is still lacking in agility, safety and modularity.