Wishful thinking

It's the converse question you need to ask: "which cases where an application writes to a file then uses rename() NOT to replace another file would WANT the ordering to be preserved?"

The first time you save a config file would be one example. Say my config file is a hundred bytes or so of XML. Each time I save it I first save it to a .new file and then rename it. The very first time I do this I am not overwriting an existing file, but every subsequent time I am.

Now in this case you can argue that the "old or new" guarantee is not really needed; if I open the file and find it doesn't contain valid XML (e.g. it's a block zeros, or it's empty) then I can ignore the file and use defaults, and get the desired behaviour. But this needs extra work; I have to check the validity of the input in a way that is not needed for any other case and as we all know, rarely-executed code is a good place to find bugs. [My server crashed on the leap second, demonstrating the textbook example of this.]

Here's another example: I download a file into a .partial file. When the download is complete I do some sanity checks on the file (checksum maybe) and then rename it. My naive expectation is that when the application next starts it will either find a .partial file from an abandoned download, which it can delete, or it will find a data file that it can trust to be valid because it was sanity-checked before renaming. I really don't want to have to re-do the checking for all previous downloads when the app starts because users already complain about start-up time.

So unfortunately, simply adding extra safety in the case where the target of the rename already exists is not sufficient for these real cases.