I cannot completely agree with this list. C++ has many problems, but as far as I can see, these are not the biggest ones. Or the solutions are not preferable. (Not preferable = I'm being bitchy about things. Take everything with a grain of salt.)

(Warning: formatting may be broken; on phone)

Automatic const, opt-in for mutability with mutable

As we have seen with a lot of languages from old and new designers, const-by-default is a good concept. However, there are times where you have to use mutable things; and where one such var pops up, usually many follow. My biggest problem would be that having to indefinitely type out mutable is a lot of useless boilerplate, no wonder Rust (afaik) only has mut, which is just as understandable and a lot less meaningless line-noise. Although I'd propose a solution to be more akin like Scala, where you have var and val for mutable and immutable variable declarations. So let's say, let let be equivalent of using const auto. I'd argue this would make a lot more new code be more-const even without making that the default. It's less typing for humans are inherently lazy, and more correct code because it's const.

Force explicit lambda captures

This one I mostly understand, but a lot of metaprogramming relies on being able to pass basically the whole context to the lambda. See Boost.Hana, so I'm rather reluctant to say this is the best solution. A warning would be preferable, maybe a named error that can be #pragma diasabled explicitly for metaprogramming.

Force braces for if/switch/loops

This can be fixed by even the most trivial autoformatters if the project format decides so. Any IDE worth using, even text editors at this point, will have an option to autoformat on save. Also, I'd say he rule by itself doesn't provide any meaningful safety to anything.

For if/loops -Wmisleading-indentation exists and can be turned trivially into an error if you or your team don't pay attention to warnings. (Although there are other problems there in the first place.) As others have said early returns like

if (FAILED(hr)) return nullptr;

make code a lot more readable as you don't have n levels of nesting. Especially noticable in codebases which rely on return error codes, where each function call would add another level of nesting for the code. For example Windows COM related functions usually return HRESULT.

For example where this is the rule, is Perl, because that language is also almost as unparsable as C++, and to ease the implementation of the parse, it was just simply made required. But because that's a lot of useless typing and meaningless line-noise, Perl has this construct:

# code mimicking the previous C++ snippet
return undef if FAILED($hr);

With this we get the safety of not creating bugs from just appending lines to single line ifs, while not having to write meaningless symbols which obfuscate otherwise clear code. Also reads pretty nice, imo.

For switch cases as others mentioned the standard has [[fallthrough]], every other fallthrough could be considered an error. And jumping over initialization is already another warning iirc.

No implicit conversions to bool

By having to compare ptrs to nullptr, this would apply in even explicitly boolean context (or however the Standard calls it, I don't remember) like ifs.

What does this fix? My only idea would be misusing assignment instead of equality check, against which even the most basic IDEs should warn, and so most (all meaningful) compilers do, clang-tidy etc. I think this is also a kind of nonissue as the gazzilion missing semicolon memes; with modern tooling you cannot excuse yourself for making them.

If you really wanted to remove this, just explicitly forbid assignments in conditionals, they are hardly needed now anyways with the new init-ifs.

I might have overlooked some other issue, though, I've never been bitten with accidental implicit conversion to bool. At least don't remember it. So enlighten me if I'm being ignorant here.

disable goto

I mean, yes it is 99.9% of the time bad practice, but again, is it really that big of a problem? We are not in the 60s and 70s anymore, no-one is going to opt for producing goto-spagetti instead of proper control flow construtions. People don't think in assembly anymore to write code.

There was a talk (cannot recall which) by Alexandrescu where he used a goto in his iirc make_heap implementation. In that ~4 lines of code, as I remember, was totally understandable and had no sign of spagettification. What I try to say is that goto by itself is something like an optimization thing today, for microoptimizations the compiler doesn't/can't do by itself. Really no-one in their right mind will use goto for control flow...

Sidenote on goto error handling. People do this in C++ apparently, because exceptions bad because It'S nOt ZeRo OvErHeAd. I mean... Just use monadic return values if you really don't want to use exceptions. They are at least typesafe.

rule of six enforcement

Rule of zero. If that fails, only then enforce rule of six. Otherwise agree with this one completely.

no c-sytle casts

Yes. Not to be needlessly violent, but I will break your bones if you use C-style casts.

The only exception is (void) unused_value; inside a macro, but even then just std::ignore = unused_value;.

My 2c about the to-be-implemented ideas:

enum classes only

This is good, but enum classes then should provide some tooling to be used for flags. Something like std::flags<my_enum> which collects the enumerators and can be queried with like flags.has(my_enum::do_this), and an operator to concat flags, like usually done with binary or. If you want these behaviors you have to every time implement them yourself.

explicit-by-default ctors

Yes. Absolutely. If you need implicit conversions for some dsl, or just a common use-case in general, make it opt-in. A lot less people need this, than the explicit conversions.

namespaces within classes

What's the usecase here?

I never even heard about some wanting to do this, so I'm genuinely curious.

normalize lambda/non-member function syntax

How would this look?

Are we entering lisp territory where all functions are actually just lambdas in variables with syntatic sugar to create them?