This is sort of where I was going with the @unknown catch idea earlier: have a way to specify a list of expected errors in the throws effect, and then allow all the expected errors to be caught exhaustively. This without necessarily disallowing unexpected errors (those not listed) from being thrown. It also allows the list of expected errors to change over time, similar to enums that can evolve, without causing issues for source or binary compatibility.
I suppose a variation of that would be listing expected enum cases in throws(...) rather than only expected types. In which case it would become some kind of list of patterns to check for, or some kind of error mask.
I don't see anything incompatible with the current proposal. They serve different purposes and can be implemented separately. But I suspect if they are added at the same time, people will be less tempted to use typed throws for the sole reason of having the compiler help you check for exhaustiveness.