So, I think you are latching on to the traditional login process too much. I was just trying to give an example, in my case the login process is way more complex than normal.
On bullet point #1: the "login" example was just that, an example. In reality, I have a situation where the user types in their username, hits next, and then an API call is made to determine which login screen to show (either the normal screen, or open a web view for SSO). In the normal case, they see a password entry screen, but should be able to hit back and see the username they originally typed in. So the original username-entry screen should remain on the stack. Simply setting a state does in fact cause you to "bounce back" to the password screen, as this is what I was experiencing. It seems the solution is that I need to be able to "consume" the event part of the state, so that the view model's state resets to a non-navigated state. I'd like to ensure that updating the state to a "nav forward" state can only result in a single navigation. One way to do this is to make a property on the ui state which is a nullable channel. If null, there is no nav event to make. If not null, then in a launched effect, observe the channel until a nav event comes through. When the event is received, the channel ensures no one else receives it, as is the nature of channels. Another way to do this is simply to have a view model method which is like "reset nav events". In a launched effect, watch the nav state property. When it's set to something that results in a navigation, before actually navigating, call "viewModel.resetNavState()" to un-do that and ensure no one else sees the event. I was mostly asking about this to see if anyone else had actual experience with it, or opinions on what is more idiomatic. Channels feel more "correct" but also a bit "over-engineered".
On bullet point #2: I think I have the back functionality sorted out, activity has nothing to do with it, my view models are tied to the navigation destination, and hitting back does pop the destinations off the back stack, killing the view model, ending that scope.
Anyway, thanks for the help, sounds like I just need to hack this together. I'll just do whatever works.