I’m with Xi on this. Supporting a notion of protocol requirements which may or may not throw, and being able to make functions using those requirements throw only if the conformance in question does, is a great feature I’d love to have—especially if we can adopt it without breaking ABI compatibility*. Reusing the rethrows keyword in protocol requirements to also specify conditionally-throwing requirements seems too clever by half.
As for IteratorProtocol, can we introduce a conditionally-throwing replacement for next(), probably under a different name, and then define default implementations for each that call the other? for can then use the old entry point for known-non-throwing conformances in backward deployment, and the new one otherwise.
This would have the same problem with mutually recursive default implementations as hashValue and hash(into:), but we really ought to productize a solution for that one day.