It's nothing to do with the back button. It's about addressability - being able to link to things. Links are kind of important on the Web.
Of course, but not in all applications and situations. What does it mean to link to the middle of a Farmville game session? It's by definition a transient state within a process that does not need re-linkability or history. Similarly, we've been using desktop applications forever with no notion of addressability. You don't send an image with the expectation that the recipient can jump into the middle of your editing actions in Photoshop.
When a web application is fundamentally about an interactive process rather than publishing content, the notion of back and history can lose much meaning. Using Back as a universal undo button or a URL to bookmark any arbitrary slice of content does not hold up in the world of more complicated AJAX partial dynamic page updates. Should designers continue to contort Javascript and the very notion of URLs to satisfy this increasingly-misplaced user expectation, or work to educate users that sometimes "Back" or bookmarking cannot have a meaningful result?
Nobody expects a "back" or "undo" button in everyday activities like driving a car or cooking or making social conversation. How did this expectation become so irreversibly fundamental in computers?
Wow. We're only just now getting to the point where it isn't possible to accidentally render your computer unusable with a few stray actions.
You seem to be forgetting just how unforgiving computers were even 8 years ago, any why iOS devices are so enticing to regular folks.
Don't conflate the two concepts. Undo good, back... not always required?
But most apps can be broken into at least a few states. For any document based app, like Photoshop, navigation should probably move between document views. Any modal dialogs should be closable with the back button. You don't have to use it for everything, it just has to do something sensible and non-destructive at any given time.
You don't send an image with the expectation that the recipient can jump into the middle of your editing actions in Photoshop.
People make mistakes. All people, in everything they do, at every level of responsibility.
"Back" or "undo" buttons in everyday activities like driving a car or cooking or making social conversation would be astoundingly useful. In your first example alone, literally tens of thousands of lives would be saved every year.
The expectation is irreversibly fundamental in computing because in computing, unlike reality, it is actually possible.
* If the back button behaviour is important, perhaps not breaking it in the first place is an appropriate approach
* The addressability of resources is one third of the fundamental basis of the Web. Ignoring it is essentially non-web, so I suggest the label "web-app" is incorrect.
* The user-expectation of clicking the back button but expecting to remain on your one-page website sounds like a usability problem brought about by applying a non-web-like interface inside a web browser. Perhaps a better user-experience is not breaking the well-understood web-navigation model, and thus not be confusing to the user. Or perhaps these "web-apps" need to make it clear to the user that they deliberately don't follow the characteristics of a web resource?
- The web application could serve static pages and then update them with AJAX
What if the user clicks back /then/? All the AJAX updates would be lost, and they'd go back to an older version of the page - they'd then see the data on the page "jump" to the updated version.
- The web application could not use AJAX at all, and serve everything as static pages, without automatic updating
Some web-applications can't work like that. Mine has instant messaging, and I want the IM windows to be there when it loads. Besides, most users /like/ AJAX. They're not thinking "oh no, this application ruined the web", they're thinking "nice, the page updated itself".
- The web application could use Flash or some other plugin, instead of the native HTML/Javascript
Which of these are you suggesting developers do instead? Why is the HTML5 history/hashbang URL model not better than all of these?
There are already internet protocols for real-time notifications, like XMPP and a whole host of non-open protocols. Re-implementing messaging on a platform that isn't by it's nature a push platform will always be inferior to the real thing.
Wouldn't it make more sense to implement a web-like application on-top of a real-time messaging platform instead of the other way around?
(Though, it's not clear what a back button should be doing in an "instant messaging" interface - will it undo the a conversation? Does a user bookmark a message or a conversation so they can edit/refine individual messages later?)
"Which of these are you suggesting developers do instead?"
I'm suggesting developers use the right tools and platforms for the job.
Well, it's pretty clear what you mean now, and I guess we'll just have to agree to differ. Real-time AJAX applications in the web browser are the future, and I know I'm not the only one who thinks so.
Also, if you think I'm trying to say the back button should do anything to an IM conversation, you're misunderstanding the whole issue.