“…the struct that was captured by the closure can become “outdated” and disconnected from the state store…”

Ummmm… true, and I suspect that it’s something to be aware of, but from a certain point of view State variables are supposed to be used to manage a view’s internal state while that view is in the hierarchy. And most of those variables are supposed to be private, anyway.

Remove the view from the hierarchy, and the net effect might like [weak self] capturing a view controller in an async closure. That particular VC doesn’t exist any more, so there’s nothing to update.

I’d have to puzzle out the rammifications. If the view isn’t in the hierarchy, then updating the “state” doesn’t matter. If it’s been replaced, then the replacement view has its own state, which you’d probably not want to overwrite anyway.

And if you did want to maintain state across invocations, then that’s probably best done in the environment, or in an ObservableObject reference type that’s maintained across view invocations.

The rotation thing intrigues me, though. Like… what’s the value of a bound text field state string if the containing view is rotated and the text field lays out differently in the newly rotated state?