#89792 demonstrates that enum changes in platform interfaces are a potential landmine. In addition to protecting against accidentally breaking things (#89862) we need a process for how to do those kind of changes.

The options I see are:

1. Always treat adding an enum value as a breaking change. There's an argument for this, because it can actually break client code. On the other hand it would make enum changes pretty hard to make, and in general assuming exhaustive handling of enums from code you don't control is often considered bad practice.
2. Require fixing our own analyzer issues in the same PR. This would actually be impossible once Add more safeties against breaking the ecosystem with federated plugin PRs #89518 is done because that's exactly the kind of thing we generally don't want to allow. In this case since the error is analyzer only it would technically be okay, but I'm reluctant to add a carve out for something that's so hard to distinguish from the error that check is designed to prevent.
3. Temporary disable that analyzer warning when adding a value:
   • In the PR that adds the value, temporarily disable that warning an the plugin group level
   • In the PR that picks up the new enum value and uses it, remove that.
     It's slightly error-prone, but not terrible.
4. Have a repo policy that everything should have a default case (i.e., treat the platform interface like we would external code). The issue here is that we would no longer get a useful signal about places that we almost certainly do want to update when adding a value.
5. Downgrade the warning to an info message for the whole repo permanently (I think this is possible, but haven't checked). CI wouldn't warn us about things to update, but humans could find them easily when doing the second PR. I think this is probably worse than 3 though, other than being slightly more convenient.