[catnaroek]

> Copy already behaves like that in Rust: a "custom" Copy impl is just opting in to the default copy implementation

Yeah, I realized that, then deleted that part of my post.

> The reason the impl is required is to ensure people write what they mean: it is backwards incompatible to go from Copy to non-Copy, so it would be unfortunate for a type to accidentally be Copy because an early version of the type happened to only contain Copy types.

In my proposal, with an ML-style module system, you can define an abstract non-copytype whose internal representation is a copytype, just like in Standard ML you can define an abstract non-eqtype whose internal representation is an eqtype.