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.
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).