In the future direction, Sequence<Element> is a generic constraint. This specific constraint was taken out of context in the comments in this thread, but in the future direction, this is written inside of an Array extension, where Element is a type parameter / opaque type. The constraint Sequence<Element> says that you have some type that conforms to Sequence where its element type is the same as the array's Element type. The angle brackets are sugar for a same-type constraint on the "primary" associated type of Sequence (which isn't a real feature yet, it's currently in the pitch stage).
With Any<P>, you're using a protocol as a "generic argument", which isn't actually a thing that's supported, and it would mean something different than Sequence<P> as outlined in the future direction. If someone wrote Sequence<P>, the P would be an implicit type parameter that conforms to P, and the underlying type would be known statically.
In this hypothetical future world, you can write any Sequence<Element> and some Sequence<Element>. The future direction suggests that we should consider allowing programmers to elide some instead of any. If we decide to never do that, all of my arguments against the Any<P> syntax still apply. I only brought up the future direction because never requiring any would prohibit us from explore this design space.
Right. This syntax for this feature is pitched over here: [Pitch] Light-weight same-type constraint syntax