Something interesting seems to happen when considering RefCell<Pinned<T>>. Am I mistaken, or does this give us “for free” the full API set of RefCell in a way that preserves pinning? We could call borrow or borrow_mut to eventually arrive at &Pinned<T> and &mut Pinned<T>, something that would needs tons of duplication to get working with the pinned reference proposal.
Now, we can’t create a RefCell<Pinned<T>>, but we could add a single method to RefCell that can turn a &[mut] Pinned<RefCell<T>> into a &[mut] RefCell<Pinned<T>>. That would be like a “one-liner to opt into pinning with the full API surface” (and it’d incur a hell of a proof obligation). Well, two-liner because we have shared and mutable references.
This seems like great news, but there’s a catch… in the pinned world, this is actually unsound because of the Deref impl! If we can turn &Pinned<RefCell<T>> into &RefCell<Pinned<T>> using the above method and into &RefCell<T> using a Deref impl, we have a problem. (Restricting the conversion method to just mutable references, i.e. &mut Pinned<RefCell<T>> to &mut RefCell<Pinned<T>>, does not help.)
So, all this magic wrapping seems nice, but it also seems incompatible with that Deref impl.