That's an option, but it's a risky one, because you could end up with a balkanized language with many different C++ dialects depending on compiler version and p

That's an option, but it's a risky one, because you could end up with a balkanized language with many different C++ dialects depending on compiler version and platform. The amount of existing code in the world is huge, and not every organization has the resources, knowledge, or desire to move to the new hotness every time an improvement to the language was made. The Python 2->3 transition is an example of what can happen when you make backwards-incompatible changes to existing language features. We're more than a decade in, and there are still huge volumes of code at major organizations that haven't made the switch. This happened despite the fact that the people proposing the change also controlled the change and release process for the major implementation of Python, a case which is not true for C++. It's also difficult because many proposed backwards-incompatible changes or deprecations would break ABI compatibility, which would prevent a library and binary (or 2 libraries) that were compiled using different compiler versions from inter-operating. This breaks a core workflow for many C++ users. To get a better understanding of the committee's priorities, I would recommend looking at "The C++ Programmer's Bill of Rights": https://isocpp.org/blog/2017/07/what-should-the-iso-cpp-standards-committee-be-doing https://isocpp.org/blog/2017/07/what-should-the-iso-cpp-stan... It's not a formal commitment from the committee, but it will give you a sense of what their priorities are.