Hmm. This depends, I suppose, on the "role" of the orphan rules. Do they exist only to prevent overlap, or also to give a degree of "ownership" to the crate that defined Bar?

I suspect the answer should probably be the former, because the current rules don't actually give that much "ownership", especially for traits that have multiple input types. But I'm not entirely sure.

This same question arose in the context of the Pin unsoundness. In particular, as @withoutboats was telling me, they wanted to be able to reason about things like "there is no DerefMut impl for &T". I'm not crazy about this sort of "negative reasoning", as it is fragile -- it wen't wrong in the Pin case because of fundamental + dyn values. But in general if our orientation is to permit "third party crates" to add impls whenever we can get away with it, that is going to make such reasoning very difficult indeed.

I agree that orphan rules should be about preventing the potential for overlap.

In this specific case the user has marked the trait as #[marker] (and therefore it has no computational content and overlap is vacuously sound), so it seems to me that their intent was to allow this. Indeed, the reason I found this problem was that I wanted to move rustc::hir::ArenaAllocatable to rustc_arena, but couldn't because of the orphan rule.

As for DerefMut (which has computational content unlike a #[marker] trait), it seems to me that one can always retain such reasoning if one wishes by simply not using #[marker] for the specific trait. ;)

Wouldn't this force us to consider that the following impl overlaps with anything?

impl <T: MarkerTrait> NonMarker for T {}

How is this supposed to interact with specialization?