Another thing to consider though is what guarantee the "sealed" invariant gains you as a programmer developing your library. As proposed, "sealed" alone doesn't give the compiler enough information to statically verify that you've exhaustively switched over conforming types, so the only statically total way to interact with a protocol interface would still be through its requirements. Therefore, while you would be getting a guarantee that code outside your module doesn't add conformances, you'd still have to rely on dynamic assertions and/or auditing outside of what the compiler checks to ensure that you're exhaustively handling your own cases in switches or other non-protocol-requirement-dispatch mechanisms. OTOH, if you factor your code such that you always dispatch your type-specific logic through the protocol's requirements, then the "no outside conformances" constraint may not really buy you anything—it may not always be practical for external types to conform, but if they manage to, there's no direct harm in their doing so.
If part of the goal of this proposal is to allow exhaustive enumeration of conformances outside of protocol requirement dispatch, then an alternative design might need to be explored. However, having a requirement like "private and local classes are not allowed to conform if a protocol is sealed" would be really weird. In languages with "case classes" to represent closed sums as class hierarchies, for instance, all of the cases must be defined together with the parent class; maybe a sealed protocol could have a way to enumerate the conformances up front as part of the protocol definition?