Basically, consider a ball of meat. The meat is rotting, nobody would eat it anymore, so fresh meat is slapped on it. And the process repeats numerous times, for years.
In the end, you'll have a giant ball of meat, that'll look fresh, but once you poke the ball, you'll be hit by the stench of the rotten meat inside.
I'd prefer if they started anew, rather than keep slapping fresh meat on the ball.
There are many good reasons to evolve a language instead of inventing a new one, the situation is a little bit like with OpenGL: 'modern OpenGL style' has nothing in common with the original OpenGL, and many ideas have been introduced in past versions which are now considered bad or dead. Still I can take the OpenGL Gears sample (which is who-knows how old) and run it on a modern GL driver.
This is both a good and bad thing. The bad is that it is confusing to learn OpenGL if you haven't been following its entire history. Googling OpenGL questions will give you 10 different answers, all correct, but only for a specific time in its history. The good thing is that this approach allows me to bring a large piece of GL code incrementally to modern standards without having to rewrite everything.
Of course there are the new fancy 3D APIs (just like there are fancier statically typed, compiled languages compared to C++), but in general, people are underestimating the risks of rewriting a large piece of code (this is still just as true as when it was written 15 years ago: http://www.joelonsoftware.com/articles/fog0000000069.html)
What I would like to see in C++ is to have very detailed control over language features and enforce coding guidelines in my own code base. The more fine grained this control, the better. Something like 'don't allow pointer arithmetics', 'don't allow C arrays', 'don't allow multiple inheritance', etc... Going with your example: as soon as the rotten meat layer is reached, the compiler would no longer accept the code unless you specifically allow it with an exception to the 'modern rule-set'.
A combination of such rules could result in a 'safe subset' which would have the same compile-times guarantees as Rust, and if the rules are violated, the compiler will complain (I think/hope this is what the presentation is mainly about).
What I would like to see in C++ is to have very detailed control over
language features and enforce coding guidelines in my own code base.
What I think some people are overlooking is the practicality of C++. From a language standpoint, there are various inconsistencies, multiple ways to do things, arguably dubious design choices, etc..., but there isn't a genuine reason those can't be avoided.
I personally would probably prefer writing all my code in Haskell, but C/C++ is still vastly more productive.
Maybe something similar to JavaScript's "use strict" would be good, including the ability to restrict it to function/class/source file scope.
Only very few flags warn or disable the use of entire language features. Most are warnings against dangerous ways of using some of the features.
I think what we need is a way to selectively disable language features. Changing the behavior of existing features is a much more questionable thing to do in my view.
The big question is if it's possible to disable some features without affecting how other features must work. It failed miserably for exceptions, but exceptions are a cross cutting sort of concern.
The whole point of this article seems to be to teach people to by default not poke the ball, unless really really needed, and in such caes do it while wearing a proper mask.
Which is not ideal (that would indeed be to start over I guess), but given the current situation probably the best they can do.
And it's sad that they have to teach people not to poke the ball and reveal the inner decay, rather than remove the rotten meat itself.
Also, it's time to lay off your metaphor, it obscures the issues and trades just on disgust value.
Modern C++ is just a subset of the language, and nothing prevents the old language from popping up everywhere.