It is difficult to explore the subject because Swift the language does not support subscripts with a different type for the getter and the setter.
Enum key paths would require an optional getter, and a non-optional setter. The getter returns an optional payload which is not nil if and only if the enum has the matching case. The setter requires a non-optional payload, because "setting the payload to nil" has no meaning.
I note that the original pitch for enum key paths did not include writable key paths.
In terms of functional programming optics, it looks like sum types can define "lenses", but product types can only define "prisms". In our case, the struct key paths getter and setter use the same type: they are lenses. But enum key paths getter and setter don't use the same type: they are prisms. Lenses are prisms, where it happens that getter and setter use the same type. I'm just not well versed enough in the techniques used by functional languages in order to bring them together and flatten their differences where possible. Obviously serious variance and contravariance juggling is necessary.
I reach my personal limits here: I'm not, right now, able to explore writable enum key paths and exhibit the changes they would bring to the language. My skills and general culture are too limited.
What I'm sure of, though, is that they will require a lot of changes. The Core Team will ask to split them into distinct proposals. I predict that writable enum key paths require an "umbrella proposal", split into several sub-proposals. And we'll need the most talentuous people.
I wish somebody proves me wrong 
Stephen, any hope? Core Team members, any advice?