Case study, by coincidental timing: @tikitu ran into issues with iOS 17 (vs prior versions) because the error handling in SingleValueDecodingContainer changed without warning. And from one undocumented error case to a different undocumented one (it actually used to throw DecodingError.dataCorrupted, now it throws JSONError.numberIsNotRepresentableInSwift, but neither of those is listed in the documentation as being what it can throw).
So a good example of why stronger typing for errors is necessary. And how ABI stability is not the same as actual stability. The ABI might be unbroken - it's still throwing any Error like always - but as this example shows that doesn't mean it can't completely break the caller in any library (or OS) update. And from my reading of @tikitu's story, it seems like the breakage was significantly harder to root cause than if it'd been e.g. a return value that changed, because thrown errors can traverse arbitrarily large spans of code by "magic", making them appear far away from their actual source (and in confusing ways, if they happen to trip into a different, otherwise unrelated catch clause).