&gt; So the perspective you might be missing is that there absolutely are broken or useless parts of the C++ standard.<p>I&#x27;m not missing it.  I feel C++ is a broken enough language that I generally prefer to use others.  That said, C++ is my day job, so I get to feel the burn and wish it weren&#x27;t so broken.<p>As a result, I&#x27;m all for getting rid of useless parts of the C++ language.  But backwards compatibility is not useless!  I&#x27;m willing to sacrifice minor, &quot;theoretical&quot; backwards compatibility for relatively minor reasons - I don&#x27;t think I&#x27;ve seen any code broken by &gt;&gt; being interpreted differently in C++11 in templates, for example.  I only know of one case where trigraphs were used intentionally - and compilers have been disabling them by default and warning about them for quite some time now (to the point where I don&#x27;t really care if the C++ standard is fixed, because C++ in the wild is fixed.)<p>But getting rid of NULL and 0 as pointers?  Breaking overrides missing the override keyword?  Every C++ codebase I know will break massively.  It&#x27;ll make C++ification of a C codebase even more of a massive pain in the ass.  Pass.  Make them enabled warnings by default instead.  Enable warnings as errors when you can.  People are already doing this for you: <a href="http:&#x2F;&#x2F;codepad.org&#x2F;R5XyUby2" rel="nofollow">http:&#x2F;&#x2F;codepad.org&#x2F;R5XyUby2</a>.<p>--------------------------------<p>RE 1:  Continued improvements to the C++ language are occuring.  C++11, C++14, and C++17 are all introducing new stuff, and providing better options for securing your code.  This does not require breaking backwards compatability.  Unfortunately this goes against points 2, 3, and 4, for reasons that have nothing to do with what&#x27;s been listed here.<p>RE 2:  I don&#x27;t see anything in this list that would help significantly there.  If anything, mandating more diagnostics about override keywords will complicate the compiler further.<p>RE 3:  So lets add some sequence points that make parameter evaluation order defined.  Lets get rid of those type aliasing rules that every large codebase runs afoul of.  Lets do some high impact stuff that will catch some really nasty edge cases that, realistically, will fix more codebases than it breaks.<p>...but none of that seem to be on this list.<p>RE 4:  A lost cause that&#x27;s getting worse.  Adding a bunch of caveats that &quot;oh, except in C++2x you can&#x27;t do this thing that&#x27;s in decades worth of C++ tutorials, examples, and codebases - including most of what you&#x27;ve seen online&quot; isn&#x27;t going to make the teaching problem any easier.  It&#x27;s going to make it worse.<p>----------------------------------<p>&quot;So... why the minor, tiny issues? Because we&#x27;re not ready for the big ones yet. Let&#x27;s get some minor issues under our belts and then we&#x27;ll figure out how to deal with bigger ones.&quot;<p>We&#x27;ve already got lots of experience under our belts with fixing minor issues.  auto, &gt;&gt;, template exports, throw() statements - all the way back to the very first standard, which eliminated implicit conversions from int -&gt; enum, void* -&gt; t* , and for loop scoping - with all the breaking of C or prestandard C++ that this entailed.<p>What will it take for us to be &quot;ready&quot; to deal with things like parameter evaluation order being unspecified - and thus at the mercy of your compiler version, flags, and phase of the moon?  Fixing that would break no code that wasn&#x27;t already broken, and eliminate a massive source of unspecified weirdness that I still struggle to explain to other C++ developers who have been coding for <i>years</i>.<p>I still have to carefully explain the difference between operator precedence (how a() - b() - c() is parsed), and sequence points (which define the evaluation order of a(), b(), and c() - or more accurately don&#x27;t).  They point to &amp;&amp; and ||, and I explain how they - along with &quot;,&quot; and &quot;?:&quot; - are special cased by the C++ standard to define additional sequence points that just happen to match the operator precedence rules - unless you overload them, so never do that - and by the end of it, I&#x27;ve either blown their minds or they still don&#x27;t quite believe me.<p>Showing them how std::cout &lt;&lt; i++ &lt;&lt; i++ &lt;&lt; i++ &lt;&lt; &quot;\n&quot;; changes behavior depending on compiler flags tends to help - although that&#x27;s cheating as there&#x27;s additional unspecified (or undefined?) behavior for modifying the same integral multiple times without an intervening sequence point...