"That compatibility has been absolutely crucial for the language's continued success" I am not sure I buy that argument. The problems with Python 2->3 were mos

"That compatibility has been absolutely crucial for the language's continued success" I am not sure I buy that argument. The problems with Python 2->3 were mostly about Guido and his management style rather than actual language. People were not sure how long Python 2 would be maintained and whether or not they would need to support both and how that would work and all sorts of things like that. And Python 3 was not very complete on release, with a lot of things changing rapidly and backward compat getting shoehorned back into P2. With C++ committee approach this is a lot less likely to be a problem. I think the reason things never get dropped is because C++ is not well designed. It is basically C with OOP and generics bolted onto it. So low level C stuff like direct memory access is built-in. And since OOP is kind of an afterthought, there is a split between parts of language that do fall under the OOP system and parts that don't. So you can introduce something like std::string using the OOP system and make it super safe, but you cannot replace C strings with it simply because C strings (and direct memory pointers in general) are a core part of the language that is not connected to OOP in any way. Same goes for smart pointers and iterators and functor structs and what not. Most of the cool things in C++11 and C++17 are firmly planted in the OOP world and cannot affect anything that is the "original C" part.