Correctness of Pin::as_mut fundamentally relies on DerefMut satisfying a particular specification (namely, "to not unpin"). So yes, this does rely on particular behavior of particular impls.
The problem is that the "safety check" (in terms of then the API surface mandates the client to check this property) for this occurs in Pin::new_unchecked, not in Pin::as_mut. We thought that this is enough, Pin::as_mut can rely on properties established by Pin::new_unchecked -- but it turns out that reasoning has some gaps. We can fill the gaps we are aware of right now, but I see no good way to convince ourselves that we fixed all the gaps. Hence the proposal to avoid that reasoning entirely.
In general, we rely on this for all small pointer types that support pinning. That was my point exactly.
Ah, good point. There are still some local requirements to check in Pin::new about the concrete instance that is being pinned.