There is something like your
forgivingOptional in the works here - though I really like the name of your method.
I'd be really interested in a better solution for this, but I'm not sure that one really exists. As seen here - even the libraries official examples suffer from these issues. I've found them particularly prevalent around navigation in SwiftUI - ex. when you have a binding that triggers navigation, upon dismissing the view you navigated to the binding's send action is fired, and if it goes to an optional reducer you get a crash.
I also recently ran into the issue you mentioned with a textfield being focused. In my particular case my reducer is able to handle the focused state and change it to false before dismissal, but that doesn't scale well and I wouldn't expect all team members to be aware of that particular gotcha - so I'm sure it'll strike again.
This also happens for network calls, for example if your modal sheet was loading something when it was dismissed - you have to make sure that the parent store tells the child one to cancel it's in flight effect. This is actually a case where I think the crash does make sense - it's user initiated and potentially wasting resources by not cancelling it (depending on when exactly you cancel it), so it would be good to know that you've forgotten to cancel it. Though even this could benefit from a more scalable way to handle cancellation/teardown, as it becomes complex if you have a deeply nested tree with an optional at the root - it potentially has to trigger cancellation of network calls in it's children's children.
Ideally the library would be forgiving when the actions are due to limitations/implementation decisions of SwiftUI that are out of the control of the developer, while unforgiving/less forgiving of things they can control. I'm not sure such a distinction is possible. Maybe rather than a
forgivingOptional() method, we need a
forgivingSend()? So UI bindings could use
forgivingSend() while leaving the optional reducer unforgiving.