Your misunderstanding is that you think T is an owned type. It isn't. A generic type parameter/type variable can stand in for any type. Thus, T matches all types, including references, and it doesn't make sense to "discern between &T and T", because a &T is also a T (except that a fully precise notation wouldn't call the type variables by the same name).
This would require specialization to solve "naïvely", but I would recommend against doing so. If you can implement a trait for all types T, there's generally no good reason not to do that. If you need borrowing and you want to allow owned data to be passed too, bound the impl with T: Borrow or implement for Cow<'_, T> only.
Another aspect in this context: The implementation is bound on : Thing, so if &… types would never implement Thing, then there would be a clear distinction between T for T: Thing and &T for T: Thing. Unfortunately for this case, reference types are special (along with a few other types sometimes called “fundamental” from the unstable marker #[fundamental] that’s used) in that downstream crates can add implementations of Thing for &Foo for references to their own local types, so there’s no way to rules out &_: Thing implementations.
I can imagine different new language features that could help here… from negative trait impls to a way to re-define/amend the set of #[fundamental] types for your own traits.
Regarding workarounds on stable… one potentially nice approach if an implementation of Thing for &T (where T: Thing) is possible (e.g. since all methods are &self methods) the implementation for call_mut could become part of the Thing trait, with a default-impl, and the implementation for references could override the default.
Great one! I already have a impl<T: Thing> Thing for &T, but I never would've thought of using it as the needed workaround. When trying to apply this, however, the Box::new(self) tells me that the parameter type Self may not live long enough and that I should add 'static (which I don't want to). What's with boxes and the static lifetime?
EDIT: nvm, forgot a + 'lifetime in the boxed variant.
Trait objects must always carry a specific lifetime, since the whole point of a trait object is that its concrete underlying type is not known. However, this means that the compiler can't infer any lifetimes related to that (abstract) type (unlike it could with concrete types). Therefore, trait objects must always carry an explicit additional lifetime with them.
However, trait objects are usually made from owning values, therefore it was decided that Box<dyn Trait> is actually syntax sugar for Box<dyn Trait + 'static> to remove some noise. Anything else must be spelled out.
Thanks! It's a little counterintuitive, but so are a lot of things. At least this particular fact is "atomic"... though it could've been more discoverable Really my first run-in with lifetimes in the + 'a position -- been wondering where those come into play
The basics are not too hard though. At least if one knows the meaning of T: 'a, then a dyn Thing + 'a trait object can – naturally – simply be created from types T that fulfill the bound T: Thing + 'a, i.e. T: Thing and T: 'a.