Interaction between `Pin` soundness and arbitrary self types

#![feature(arbitrary_self_types)]
use std::marker::PhantomPinned;
use std::ops::Receiver;
use std::pin::Pin;

trait MyTrait {
    fn hello(self: Pin<&mut Foo<Self>>) -> Pin<&mut Foo<u32>>;
}
impl MyTrait for u32 {
    fn hello(self: Pin<&mut Foo<Self>>) -> Pin<&mut Foo<u32>> {
        self
    }
}

struct Foo<T: ?Sized> {
    _pin: PhantomPinned,
    val: T,
}

impl<T: ?Sized> Receiver for Foo<T> {
    type Target = T;
}
impl Unpin for Foo<dyn MyTrait> {}

fn pin_it(r: &mut Foo<u32>) -> Pin<&mut Foo<u32>> {
    Pin::<&mut Foo<dyn MyTrait>>::new(r).hello()
}

In the above piece of code, I'm able to convert a &mut Foo<u32> into a Pin<&mut Foo<u32>> even though the type Foo<u32> is !Unpin.

I'm not sure if you can concretely abuse this to trigger UB right now, but it seems bad.

Related test case:
https://github.com/rust-lang/rust/blob/b5e038d7158c1af55a646027fdacf5ecd7c783c7/tests/ui/coercion/pin-dyn-dispatch-sound.rs#L1-L19

https://github.com/rust-lang/rust/blob/b5e038d7158c1af55a646027fdacf5ecd7c783c7/tests/ui/coercion/pin-dyn-dispatch-sound.stderr#L1-L6

Start with the reproducer in the issue and the related tests in tests/ui/coercion/pin-dyn-dispatch-sound.rs and its .stderr file. Run that UI test, then investigate the interaction between arbitrary self types, Pin, Receiver, and Unpin; done means establishing whether the conversion is unsound and documenting or implementing the required compiler behavior.