Knowing what I do now, I might have choose to implement everything in a single screen (since the current multi-screen representation requires duplicating the core item list three separate times, which is kind of stupid). I might even re-architect the app(s) at some point in light of that.
Fortunately, my design more or less already implements a “manager screen”, all the navigation is back and forth from and to Screen1, none of the screens directly navigate to or from any other screen.
That said, within the bounds of the current application, and generally with screens, it is non-intuitive that “open another screen” doesn’t implicitly close the current screen (which I assume is the problem). I think the difference in behavior I saw was the fact that on some screens, I was choosing “close screen”, and on others, I was explicitly having the action of the Home button be “open another screen” (Screen1), mostly because it was annoying that the “Home” button behavior wasn’t consistent when using the “Live Testing” option (i.e., if I got to the current screen by navigating within AB, it didn’t return me to Screen1). I also did this, because I thought that moving between screens by doing something other than going back to Screen1 might happen in the future, and the inconsistent behavior would manifest itself and require a redesign.
I see the procedural method of closing a screen, etc., and my thought is that this should really be a control item. I.e., there should be an option to “close screen” attached to “open another screen” or a way to tie the two together without having to create a specific procedure. This would make the fact that you’re leaving the current screen open very clear.
I modified one of my apps to use “close screen” everywhere when the “Home” button is clicked, and “close application” now works as expected. I’ll revert back to that behavior everywhere. I suppose I should use the procedural method, which insures the expected behavior even if I do implement some direct screen to screen navigation, but it feels really “hackish”; as I said, the functionality should be “native”, via a “control” block.
Secondary question: do I really have to map the “back button” to “close screen” on every screen? What’s the default behavior? I have a list picker, and it seems that this would create a conflict of expected behaviors if hitting the back button resulted in the entire screen being closed.