And no, C++ just doesn't make the same things easy or clean.
And no, "discipline and appropriate rules" were never enough.
The biggest innovation of Rust is bringing some of the good ideas from functional programming to low level programming. I'd also say that partially exposing data flow analysis to a proframmer is new.
Rust package management is quite good, and also not by any means an invention.
I am still not a fan of all the ugly macro programming systems and verbose syntax in the language.
The language I really want is somewhere inbetween those two languages.
The broader ML-like type system in Rust is not novel, but the integration of the borrow checker -- and its move semantics more broadly -- with it in its form honestly is an innovation. And one I'd have a hard time living without at this point.
If by discipline, you mean running something akin to the borrow checker in your head, that's essentially tautologically true. The issue with that is that it's mentally draining and/or you will still make mistakes sometimes.
For maximum safety, beyond what Rust offers by default, in C++ it is easy to replace the built-in integer types with custom integer types, which check for overflows and allow only the correct type conversions. It is also easy to define distinct types for various kinds of physical quantities, for increased safety.
You do not need to run anything in your head. With appropriate type definitions, a C++ compiler will do anything that is required.
The problem is that because of the requirement for backwards compatibility, C++ is a huge junk collection. I think that more than half of C++ consists of obsolete features, which should never be used in new programs, and this is a serious difficulty for newbies. There are various C++ style guides, but in my opinion even most of those are not very inspired.
Despite of its defects, C++ still has the advantage of extreme customizability. It is easy to write programs that appear to be written in a language that has no resemblance with C++ (inclusively by having different keywords and what appears to be a different syntax), but nonetheless they are valid C++ programs.
Such a customized C++ variant can mimic any safer language.
The work to try to address this for C++ 29, half-finished and untried as it is - is extremely restrictive, you'd likely hate it, and that's just to solve this, the relatively easy problem.
Thing is, Rust wasn't content just to solve that easy problem. (Safe) Rust also doesn't have data races. The C++ standard doesn't say very much about data races, can't help you ensure they don't happen - it just explains that if they do that's Undefined Behaviour, game over.
This completely misses the point.
That is really not very different of rules enforced by the Rust compiler.
For someone who does a fresh start, using a Rust compiler may ensure safer programs out of the box, but that does not mean that the same results cannot be achieved by alternative means when using other languages, when the use of those languages makes sense for other reasons, and it is worthwhile to invest resources in making appropriate libraries and tooling.
In general, I recommend against the use of C++ in new projects, but I see much too often claims about things that are supposedly difficult or impossible to do in C++, which are just false.