If C++ adopted a way to namespace safe or unsafe code (unsafe by default would keep retro-compatibility) and had the tooling needed to catch memory safety bugs at compile time, that would be enough for me.

The effort needed on tooling would be significant though. I don't see that happening and overtaking Rust.

(btw the correct spelling is Achilles, Achilleus, Akhilleus, Ἀχιλλεύς)

I feel the same, despite its warts I still like coding in C++.

VC++ has some annotations on that sense, problems are two fold, get the vendors to agree, and the C subculture that security actually matters.

Thanks for the correction.

GNU and Clang toolchains have useful diagnostic abilities in this direction, though no single "master switch".

For example, with -Wold-style-casts you can diganose every use of the (TYPE) EXPR casting notation, which is often seen in the lower-level C-like C++ code for punning memory.

Somewhere in some commonly included header for the project you can write declarations for C functions that should not be used, marking them deprecated. Then if people introduce strcpy or malloc or whatever you don't want, that can be diagnosed (and can fail compilation, if desired).