It's a real semantic difference, not a pedantic detail: It means that there is a practical reason that the moved-from object could be non-empty.
A few standard library types do guarantee that the moved-from object is empty (e.g., the smart pointer types).
For some others (basically, all containers except string), it is not explicitly stated that this is the case but it is hard to imagine an implementation that doesn't (due to time complexity and iterator invalidation rules). Arguably, this represents a bigger risk than string'e behaviour, but it's still interesting.
>It's a real semantic difference, not a pedantic detail
What's the semantic difference? Of course moving a class will involve some amount of copying. How could it be any other way? If you have something like struct { int a[1000]; }, how are you supposed to move the contents of the struct without copying anything? What, you take a pair of really tiny scissors and cut a teeny tiny piece of the RAM, then glue the capacitors somewhere else?
> how are you supposed to move the contents of the struct without copying anything?
By taking the physical page this one struct resides in, and mapping it into the virtual address space the second time. This approach is usually used in the kernel-level development, but there has been a lot of research done since the seventies on how to use it in runtimes for high-level programming languages.
Now, it does involve copying an address of this struct from one place to another, that I cede.
A few standard library types do guarantee that the moved-from object is empty (e.g., the smart pointer types).
For some others (basically, all containers except string), it is not explicitly stated that this is the case but it is hard to imagine an implementation that doesn't (due to time complexity and iterator invalidation rules). Arguably, this represents a bigger risk than string'e behaviour, but it's still interesting.