I notice you’ve changed your problem statement!
Problem 1 in your draft text is adequately solved by the proposed solution:
Boilerplate: Developers regularly write verbose boilerplate to handle associated values. This is a serious ergonomics issue that lingers from Swift’s inception.
Solving that problem doesn’t require synthesizing properties for enum cases without associated values, however.
Problem 2, as written here and in your draft text is also adequately addressed by the proposed solution.
For cases with no associated value, synthesizing an accessor to a nonexistent payload is…well, that’s why we’re all calling this the “edge case.” It’s not clear to me that keypaths would be any less complete without such a paradoxical feature. So again, I think the issue is adequately addressed without synthesizing properties for cases without associated values.
The proposed solution does not actually solve the problem where “testing enum cases is verbose and inexpressive” (your reformulated problem 1) but rather presents a workaround by compiler magic. [To be clear, I’m not voicing an opinion as to whether I agree with the problem statement or not.] With the proposed solution, actually testing enum cases doesn’t become more expressive; rather, the proposal is to synthesize members that substitute for those enum cases for the purposes of testing, which in turn rely on existing compiler support to be more ergonomic to use.
I think this reformulated problem and the presented solution are rather mismatched; your draft text, on the other hand, goes into a wonderful discussion under the headings of “Associated Values,” “Deep Nesting,” and “Key Paths” all of which are laser focused on cases with associated values, and (not surprisingly, therefore) that’s where you’ve proved the worth of your solution.