However, I think there's a better solution, which is to always display the tabbed view when your app starts, regardless of the login status. In general, tabbed views are expected to be the permanent "root" of an app.
I may need to experiment with this specifically for the Login View and the rest of the app.
Regarding the NavigationView/Stack having a similar issue, though, we have a flow that may be a bit wonky if we tried to treat it similarly. We have a modifier view responsible for gating functionality behind a condition.
To avoid the issue documented above for this, I see two approaches:
Present a modal over whatever you want to be locked with an opportunity for the user to see the sensitive content.
Require handling this by the referring View and ViewModel and only present the intended destination once the condition is met. (less easy to share handling in various parts of the application)
From a code structure, shared handling, and modeling perspective, it seems much easier to have a ViewModifier conditionally present the Navigation flow (which uses a Nav View) when needed and show the intended destination when authenticated, regardless of presentation context.
For this case, I don't see much of a workaround to guarantee unnecessary work isn't performed without more work on the referring views, potentially showing sensitive content before gating with a shared modifier, or using the debounce + cancellable behavior described above to work within the constraints of this bug.
