I wasn't quite precise when I said the ViewModel's lifecycle is tied to the ui lifecycle. It is tied to it but with some caveats as you can see here:

https://developer.android.com/topic/libraries/architecture/viewmodel#lifecycle

If an Activity is destroyed due to configuration changes, the ViewModel will not be destroyed but it will be destroyed when the Activity is no longer needed (e.g. when you call finish() explicitly and obviously on process death). From the officel documentation:

> ViewModel objects are scoped to the Lifecycle passed to the ViewModelProvider

The ViewModelProvider is the Activity (or the Fragment).

Thanks for the tips about navigation! I think the framework itself should offer different ways to handle the navigation including allowing to persist navigation state if the user of the framework decides, it's the right thing for the app. Maybe in some cases keeping navigation state around makes sense like when I'm in an onboarding flow (I'd like to keep what I already entered and not have to start over, even if the app was killed). My approach will likely be to give the user of the framework a choice on how to manage navigation state.