Yes, "any" feels quite natural, doesn't it? 
If you were going to really declare a function which can accept any Protocol, you would have spelled it as func foo(_ p: any Protocol) instead of func foo(_ p: some Protocol). If we stick with the IMHO simpler model that some is decided by the callee independently of the position (either argument or result position), we can obtain a model coherent with the current implementation of opaque types.
I don't think that treating func foo(_ p: some Protocol) as a sugared alternative to func foo<T: Protocol>(_ p: T) can lead to a sound type system. After all if it were, then you would also have the following as alternatives to the same function which is not true:
func foo() -> some Protocol
func foo<T: Protocol>() -> T
The difference between generics and reverse generics is in who decides the type, the caller in the first case and the callee in the second one. Opaque types are modeled after reverse generics and not generics.
It shouldn't. Struct may be defined in another module as private and may change among future releases of the module. If you were allowed to pass the underlying type, you would "break the contract" of opaque types.