Again, one step in the direction of C++ (and the associated feature creep). I would have to agree with @matklad on this one — Rust’s memory model is fundamentally dependent on the property that "move is memcpy". It beautifully fits basically all the non-niche use cases.
I strongly doubt that changing one such, such fundamental, core idea of the language from trivial to moderately complex would be a good idea in any case. Just think about how many places this behavior is being relied upon — I don’t want to imagine the number of bugs (security or otherwise) a change like this is going to inevitably incur.
Also, a comparatively smaller, social problem is that people will think “oh, Rust now has move ctors, let’s use them all over the place because they are how we make programs fast; after all, they were how we made programs fast in C++!” — and it will creep into the non-niche code as well, and no amount of linting will be able to undo that damage (because, let’s be honest, in reality people mostly just #[allow()] if the linter is complaining.)
So, I wholeheartedly disagree with the idea of making moves non-trivial for the sake of some corner-case problems or features, especially given that it might not be the (only) solution to the aforementioned minority problems.