You are ignoring cases where you want to present your changes in an atomic fashion to other systems and people. I don't need my compiler to be churning on code that I know won't compile and I don't need dropbox constantly reuploading binary files that I am in the process of modifying. What is the point of burning network IO every time a user drags his stylus across an image in Photoshop? Atomic interactions are the future, not the past.

Furthermore, "forking" is what happens when you "check out" a file to memory and "merging" your changes occurs when you write them back. You are only modifying the terminology. Replacing the "save" verb with "merge" would not be doing the user any favours.

I'm not ignoring them, I'm just saying they aren't common. The hole point of bookmarking a version of the document is to flag it for special treatment.

I'm totally for getting rid of the discrete "compile" and "debug" icons in the IDE, my research centers around that.

So if you are running an application and editing a config file at the same time, that becomes undefined behaviour? No thanks... I'll keep my atomic interaction.

Do you also continuously merge your feature branches with mainline in realtime?

So wait, the application doesn't have a settings tab, but rather an old-fashioned config file instead? When presented with anachronistic interactions, I think you are completely justified in demanding anachronistic interactions.

Don't use high-level word processors to edit your config files, problem solved. But don't demand that our word processors to behave like your text editor that you use to edit config files.

There's more mental overhead involved in forking/merging that simply saving to a flat file. This is why source control has a higher barrier to entry than archiving old versions to zip files.