The result would be identical, so what's the point?

At most, it would prevent simultaneous uses of both the original and the copy, but given that those uses could only be in the same block with the move operator... the difference for the user is almost precisely 0 (modulo rounding errors).

I personally consider opt-in Copy to be one of the 1.0 mistakes - I sadly weren't able to implicate myself in the decision process for it, nor did I have a better alternative at the time.

Opt-in Copy was designed to protect from unsound unsafe code, which largely means pointers.

The Send model, where *const T and *mut T do not implement the trait, and structures containing thrm have to opt-in, would solve the problem beautifully.
Yes, some people have complained about that one, but so far, from them, in defense of more permissive behavior, I've only seen dangerous unsafe code with not enough abstractions - allowing either misuse of a safe API(!!) or making it very hard to reason about - both things which we want to defend against.

On the other hand, opt-in Copy tries and fails to: * prevent large copies - [u8; 1 << 31] isCopy- this is better done with a lint, which could have a custom threshold and even take optimizations into account (one can already--emit=llvm-irand grep forllvm.memcpycalls with a constant length) * prevent copies of values that represent "resources" which aren't unsafe to duplicate or forget (which is why they don't implementDrop), but doing so is likely unintended - the only example I know of isDatum` in the compiler, which has to behave like a linear type for rvalues, mimicking the actual language semantics (an rvalue is either used or dropped, but drops are explicit uses during translation) - this really wants linear types and/or being dependently typed on the Rust type of the held value (would that be meta-recursive?)

Both of those cases get a warning telling the user to add #[derive(Copy)], which means it's even less effective by default.
And we're still missing the ability to (unsafely) implement Copy on wrappers around types which are not affine, but don't implement Copy themselves - something you can do with Send.

That said, I'd be happy to find out there's actually a good reason for the sad state of affairs and I welcome /u/pcwalton and /u/nikomatsakis to prove me wrong.