The popUntil above unconditionally clears the navigator stack until there is only one route left. I believe that this is equivalent to HomePage.navigate, which also pops all routes beforehand.

Either way, we should not pop all routes unconditionally, because it doesn't feel like great user experience when the existing routes already belong to the same account.

#F1210 suggests that we

switch to a new nav stack for the notification's account (if different) before pushing the message-list route.

I think what we need here is just a way to keep track of the currently active account, or a way to inspect the navigator stack without actually popping the routes.

See discussion here: #mobile > Beta: after open via notification, back opens old server @ 💬. Feel free to ask questions if you have any!

Based on my current implementation, I have addressed the following:

1. Inspect the navigation stack without modifying it by using popUntil with return true.
2. Only switch accounts (via HomePage.navigate) when the notification is for a different account than the current one (currentAccountId != route.accountId).
3. When the notification is for the current account, preserve the existing navigation stack and simply push the new route on top, providing a better user experience.

nit: we can use Route<void>? instead, to avoid dynamic.

I think this popUntil only looks at the top-most route, but that's insufficient when that route is not an AccountRoute, e.g. switch-account page.

A way to check the status of the navigator stack without popping anything from it is through a NavigatorObserver. _PreventEmptyStack is an example of it.

I think we can have another observer that implements callbacks where a route is added to the navigator stack (namely didPush and didReplace), and keep track of the last time an AccountRoute was pushed, and the associated account ID, to implement this idea.

For tests, we can use TestNavigatorObserver to keep track of the routes on the navigator stack. Search pushedRoutes and poppedRoutes, etc. for examples of how we do it in tests.

I think we want to check that the route under the AccountRoute associated with accountB gets popped because we are opening a notification for a different account.

From the perspective of testing, it is less interesting that topRoute matches the route for the notification.

Similarly, let's try to structure this test with a TestNavigatorObserver, so we have a better idea of what happened to the navigator stack.

We should also have a test where the top-most route is a non-AccountRoute.

When currentAccountId (i.e., account ID associated with the top-most route) is null, routes below the top-most route can still belong to the same account. HomePage.navigate will pop those routes even though they belong to same account that receives this notification.