[nl]

This consistently confuses me too (and I much prefer it when application insert artificial pages).

I've thought about it some, and I think the problem is that the back button lacks the concept of context.

In the music app example, when I first use it I get the front screen, then choose a song.

Then I press the home button, put my phone away and at some point the song stops.

Now, some hours later I open up the music player from the home screen and it is still showing the song, what behaviour should the back button have?

I think it should take me back to the song list (because I am now in the "Music" context in my head - and this is what it now does). But one could argue that the back button should take me back to the home screen.

[duckworth]

The biggest problem for me is the uncertainty and inconsistency. Do you always remember the previous screen you were on in any app hours ago? What if you got to the song from some other screen? I would constantly have to "guess", what is this app going to do, take me back to where I previously was or to a higher level in the app. It needs to be consistant, back is back and navigating within the app needs to be obvious and on the UI itself.

[nl]

The back button in browsers is often used as analogy, but how many tabs/windows do you have open in your browser? What if pressing the back button in the browser switched you to a word processor because that is what you were looking at before.

[babebridou]

That's what alt+tab and ctrl+tab are for. The confusion comes from the use of only one back button instead of one per hierarchy.

On android we have only one system-wide consistent timeline to work with, and that's the timeline of fired intents. It works across the whole system. Back works on that level by default and is defined by default as "go back in time".