Ok. Two new features then: one to support generalised super type constraint, one to create relation between S and any P. But still, IMO, it is orthogonal to the proposal.
Off-topic
I was starting a discussion about the second one, and will be happy to write a pitch after this proposal is approved. I think it provides a better alternative to self-conformance, and can help to eliminate self-conformance from the language. And also addresses use cases not covered by self-conformance. If you are interested in this topic, please comment in that thread.
If would not be a metatype, maybe we can call it a metaprotocol. Of type P.Protocol. Not to be confused with old P.Protocol aka (any P).Type! Ok, let's call it P.Constraint to avoid confusion.
Then I guess you want to write something like this:
func bar<T>(_: T.Constraint) {}
// ^- error: cannot use 'Constraint' with non-protocol 'T'
So first, you need to express that T is a protocol:
func bar<protocol T>(_: T.Constraint) {}
But once you have it, you can write:
func bar<protocol T>(_: (any T).Type, _: T.Type) {}
which addresses your initial intention without T.Constraint. So my conclusion is that so far we don't need meta-protocols.
You'd need them to operate with protocols in the runtime. But currently I cannot think of any use cases.