To the best of my understanding, no such complex special-casing is necessary for SE-0280. Instead, we can mandate that witnesses backed by enum cases must have the same ABI as the corresponding property/method, and use thunks to mediate between the enum case and property/method representations.
To be honest, that was my expectation all along. By default*, protocol conformances don't reveal how their requirements are satisfied, i.e. clients are not allowed to "devirtualize" a call through a conformance if the conformance is in a module that has library evolution enabled. Additionally, protocol witnesses already have a different ABI than normal functions because the conformance is passed in, whereas for normal functions on an enum you know the concrete type you're working with. So (IIUC) there's almost certainly going to be a thunk anyway.
The point I was bringing up wasn't really about conformances at all; it's more about enums in general. It's not binary-compatible to replace an enum case with a static property or a static function with an enum case, even if you ignore matching, because enum case construction doesn't go through any sort of function call at all today. That's true whether or not it's satisfying a conformance, though we certainly could make the rule that any enum case generates a "shadow property/function" that you can call (at the cost of extra code size).
* That "by default" can actually be a problem in practice; currently the devirtualization of conformances is tied to whether the conforming type is frozen, which isn't really correct. I mentioned this very briefly in Backwards-deployable Conformances, since that's where I was proposing an attribute syntax for conformances.
The wrinkle that SE-0280 adds is that you're making additional promises: not only does this case claim a name forever, but also that name has to satisfy the requirements of the protocol forever. That's why formalizing @_implements would be a way out in this particular case.