Unfortunately, move semantics in C++ is broken, and will remain so until the type system finally understands that `std::move` is supposed to invalidate the original object. But, this being C++, I won't hold my breath.
Trying to fix this with the type system doesn't really work. Tracking the changing attributes along a path of control flow with the type system requires an insanely complicated type system.
Rust's borrow checker understands invalidation via move, and lots of other changes in variable state which occur along execution paths. That seems the way to go. But it has to be integrated into the language design. As a backwards compatible bolt-on to C++, it just won't work.
(It's been tried. I tried once, about 10 years ago, and gave up. I talked to the designers of Rust, and they tried and gave up. There have been other attempts to get C++ ownership under compile time checking, and the result is either a new incompatible C++ variant or something that leaks like a sieve. Ownership needs to be a fundamental language concept independent of type)
The C++ Core Guidelines aren't always mechanically enforceable. Experience shows that unenforceable rules will be broken. After all, what's undefined behavior, if not an unenforceable “don't do this” rule?
I thought moving will leave the original in some valid state. For example moving a vector may leave the original object as an empty vector. What's so broken about that?
The very concept of a nullable pointer is problematic, because it means that every dereference operation is potentially unsafe.
The only satisfactory solution is to enforce, using the type system, the rule that moved objects can't be reused. Unfortunately, C++'s type system can't express this.
The point of move semantics is to enable use of values instead of pointers. That's even better/safer than using references.