I have come around to the idea that static should be dropped. What persuades me is not just the compositional argument, but the future direction toward extension P.Type. For P.Type, instance members are not optional — different conforming metatypes are distinct values, so members must dispatch on self. If P.Protocol extensions use static now, we'd end up with two metatype extension forms that work differently for no reason a user could easily explain. Dropping static on P.Protocol establishes a uniform model: metatype extensions add instance members to metatype values, whether there's one such value (P.Protocol) or many (P.Type).
That said, I do have a concern about approachability. The lack of static is technically correct, but the reader must understand what instance the member is being bound to — "the singleton metatype value P.self" is not a concept most Swift developers have thought about. Throughout the rest of Swift, static signals that a member belongs to the type itself rather than to an instance. The question is whether we should take @xwu's point to heart and begin making the distinction visible — that static members are not truly "on the type" but sugar for instance members on the metatype. Should this proposal be the place where that becomes explicit?
The original design trades off mechanics for the mental model. I can appreciate how static is inaccurate in this position, and the future-evolution story is what tips me toward dropping it.