IMHO, in SwiftUI (and almost every other language in which it's used) Redux-style systems are fine for small apps, but one they reach a certain size you start having to worry about performance issues cropping up on every state change, as making a global state change every single time the user does anything ends up causing the app to diff the entire view tree looking for changes.
Local state, MVVM, and micro-service architectures are much more suited to SwiftUI than Redux.
I know architectures are like religion, but the amount of workarounds that seem to be needed to alleviate your pain points (including requesting changes to Swift itself) seem to me to be a great example of why Redux-style systems are NOT perfect for SwiftUI. It's simply not how it was built.
These changes can be motivated equally well in vanilla SwiftUI. As soon as you have enums in your view model, you start needing things like dynamic member lookup for enum cases, which requires closing the key path gap between structs and enums.
You just repeated my own observations about view diffing back at me, and I definitely don’t agree with your logic. I could have said the exact same thing about the actor model that’s currently being shoe-horned into Swift, but languages need to evolve to accomodate new and grander things.
Redux as an architecture provides concrete benefits that others cannot, by virtue of their implicit nature. It’s easy to sweep the reasons for choosing Redux under the rug as “religion” but I’m a pragmatist, not a zealot.
But this post isn’t about Redux, that’s just the biggest pain point for me. Case paths / unassociated enum cases would provide a boon for any Swift engineer, as Stephen said above.
I would like to see case paths with ergonomics as close to key paths as possible, too.
In particular, I would like to be free to use all the features of Swift (like enums) to model my domain in a logical way that avoids invalid states and feel confident I can use those models with things like bindings in SwiftUI, without writing clunky, awkward boilerplate-y code.
While the above is abstract, the Point-Free series on Composable SwiftUI Bindings explains the problems clearly -- with examples -- and outlines how case paths can help solve the problems. If you don't have a subscription (which I highly recommend, fwiw), then the transcript and source code is available to read.
The absence of this is often a glaring and annoying gap. In those situations, an intuition developed with key paths as a Swift developer has lead me to reach for such a tool when none exists.
Bikeshedding the naming: I recommend Discriminator instead of Unassociated, since "discriminator" is the name of the component of an enum case shorn of its associated values.