It's not true that the only sensible choice for a moved-from object be equivalent to the defaulted constructed one.
If your move constructor doesn't exist then the copy constructor gets called under the language rules, so the sensible default is actually a copy.
Everything else is an optimisation that has a trade-off
A conforming implementation of std::list, for example, can have a default constructor and a move constructor that both allocate a sentinel node on the heap, which is why none of the constructors are noexcept.
If you don't allocate a sentinel on the heap, then moving std::list can invalidate iterators (which is what GNU stdlibc++'s implementation chooses).
I did not say “default-constructed”, because that’s a whole other can of worms.
But yes, the implication of C++ move semantics is that every movable object must also define an “empty” (moved-from) state, so you cannot have something like a never-null unique ptr.
Specifically, it is not allowed for the moved-from object to be inconsistent or to say “using it in any way is UB”, because its destructor will run.
It's not true that the only sensible choice for a moved-from object be equivalent to the defaulted constructed one.
If your move constructor doesn't exist then the copy constructor gets called under the language rules, so the sensible default is actually a copy.
Everything else is an optimisation that has a trade-off
A conforming implementation of std::list, for example, can have a default constructor and a move constructor that both allocate a sentinel node on the heap, which is why none of the constructors are noexcept.
If you don't allocate a sentinel on the heap, then moving std::list can invalidate iterators (which is what GNU stdlibc++'s implementation chooses).
It's a trade off.