This is based on reading When Good User Interfaces go Crufty. I didn't think I'd be able to find a comment again in the discussion.
Saving is now an operation that users care about. It's actually more like committing changes. Users expect, from their computer use, to have the times they saved as times they can revert to (at least the most recent one). But they also don't necessarily have the habit of saving often (and they shouldn't save often, by the meaning they're using; they only should save when they've completed something). The correct behavior is to keep track of changes since the last save and apply the most recent set when the program starts up. You can quit, crash, lose power, whatever, and it will come back where you were. But if you (e.g.) copy the file somewhere else, it won't be different, because you haven't saved it. And there's no need, on a modern OS, to actually ever write the in-progress version with file operations: you can memory map it and the OS will write it to the disk as needed, avoiding the possibility of the program crashing with unsaved work.
While I'm on the topic, undo past saves is a useful idea (as is multiple versions), but it should stick to the session, not to the document. "Sure, I'll delete the secret parts of the document and send it to you." The user-level concept of a file has only a single version, with nothing but the current contents. Everything else is magic that the user expects to be personal.
Programs should quit when you have closed all of the windows, and not at any other time. If each window is a document, it quits when you're no longer working on any documents. If there's a window for other stuff, you'd have to close that, too (e.g., in an IDE, you'd have to close the IDE as well as the documents). You can't close the IDE part unless you're closed all of the documents (although, possibly, if you try to close it, don't use it, and close the last document, it should go away, so you can do things in any order).
Programs which can handle multiple documents should recognize when the program is already running and open the document in the existing program when you open a new document. This is often supported, but not frequently enough that users tend to do it instead of using "Open". Note that this applies just as much to the command line as GUIs; why can't I do "emacs " in a shell instead of ^X^F and then finding the file? (actually, I can. But it was complicated to set up.)
Remembering inodes isn't right, but there's a similar idea: hard links. You have two directory entries for the same storage. Of course, there are a number of questions remaining. If you move your document to a new name and create a new document with the old name, which do you get? This is essentially the situation you get when saving later versions of documents (except that the old version is also removed). Hard links would tend to follow the versions. You probably want to add a flag on files to say that it is "weak", such that, if there are no non-weak links to the file, it goes away, unlinking all of the weak links (unless any of them are open, perhaps); that would let you purge documents which are in the "recent" list but have been removed. It would make sense to have symlinks in your recent list as well, though, so that, if the original is gone but there's a document with that name still there, you get that. (Doesn't help for documents which have been moved and then replaced without notice, though).
