Reusable types and negative reasoning for marker traits

Currently the compiler is unable to reason about certain things in the type system that are obvious to the programmer. For example, a &mut T can never be Copy, and yet the compiler will reject the following:

trait Foo {}
impl<T: Copy> Foo for T {}
impl<'a, T> Foo for &'a mut T {}

Because it thinks they might overlap.

This is problematic because it makes it impossible to abstract over certain useful things, like whether a type is "reusable", ie. the set of types for which example2 is valid:

fn example1<T>(a: T) { }
fn example2(a: ReusableType) {
    example1(a);
    example1(a);
}

(This is not the same as T: Copy, because a &mut T would be valid here due to rust's automatic reborrowing)

If you try to represent this with a trait, you run into the problem above:

trait Reborrow {
    fn reborrow<R, F: FnOnce(Self) -> R>(&mut self, f: F) -> R;
}

impl<T: Copy> Reborrow for T {
    fn reborrow<R, F: FnOnce(Self) -> R>(&mut self, f: F) -> R {
        f(*self)
    }
}

impl<'a, T> Reborrow for &'a mut T {
    fn reborrow<R, F: FnOnce(Self) -> R>(&mut self, f: F) -> R {
        f(*self)
    }
}

This particular example could be solved by making the compiler aware that &mut T can never be Copy.

In general, the compiler could apply negative reasoning to marker traits: since implementing a marker trait for an existing type is already a breaking change, there's not the same backwards compatibility problem as there is with normal traits.

Start with the overlapping impl and Reborrow examples in this issue, then review Rust's marker-trait and coherence rules. A useful outcome would define the proposed negative-reasoning behavior and its compatibility boundaries; no implementation files or tests are identified here.