Comment by galangalalgol

The suggestion seems to be for api changes where the api is generated from an idl. So proto or something. If my service was built several versions prior to that value being added then I by definition don't care about it. The catch all is fine. If other services care that I don't care, they can file a ticket. You could be nice and leave out the catch all and then the deserialization will panic or throw and error. And the mect CI pipeline where the new IDL gets used will fail to compile. Both ways it is a runtime error at first. If you don't require exhaustive at all, that just lets you persist the situation without migrating my old service to the new api... Non exhaustive is the one option I can't agree ever makes sense.