> "valid but unspecified state", not in an invalid state
That's mostly a detail because you can't rely on that to do anything interesting. Basically you can assign a new value to the object, or just destruct it. Having a "valid" but unknown value is completely useless.
What is sad is that the same mechanism has been overloaded for at least 2 different things: simple perf optim (when you fall into this situation of no guarantee), and movable unique ownership (like unique_ptr) where you actually can read the resulting object after the move an expect a predictable (in a portable and standardized way ) outcome.
I'm not confusing anything, and the spec very explicitly notes that a moved-from object is in a "valid but unspecified state", not in an invalid state.
> The standard guarantees that the object is still around.
The standard's guarantees are significantly stronger than that, and furthermore
> But because its data got stolen, its internal state must now be something invalid or empty depending on the semantics of the object.
That is absolutely not a hard rule, a trivial move constructor is a copy constructor and does not affect the moved-from object in any way.