> only removes one specific kind of unsafety

the word "only" doesn't really belong in that sentence, because these are very common in root-cause analysis of flaws by the "Common Weakness Enumeration" initiative:

https://cwe.mitre.org/top25/archive/2024/2024_cwe_top25.html

and having said that - I agree with you back :-) ... in fact, I think this is basically "the plan" for C++ regarding security: They'll make some static analysis warnings be considered errors for parts of your code marked "safe", and let them fly in areas marked "unsafe".

If the C++ committe can make that stick - in the public discourse and in US government circles I guess - then they will have essentially "eaten Rust's lunch". Because Rust is quite restrictive, it's somewhat of a moving target, it's kind of fussy w.r.t. use on older systems, and - it's said to be somewhat restrictive. If you take away its main selling point of safety-by-default, then there would probably not be enough of a motivation to drop C++, decades of backwards compatibility, and a huge amount of C++ and C libraries, in favor of Rust.

And this would not be the first time C++ is eating the lunch of a potential successor/competitor language; D comes to mind.

Sure, but those are lists of weaknesses, not of bugs. Of course most of them would be memory errors. A program can play entirely by the rules and still display incorrect behavior. Consider for example the Mars Climate Orbiter bug. No amount of memory safety could have prevented that (although C++ could have been able to encode the unit information in its type system).