Surely the solution is just to put an implicit write barrier between the file content data being written and the file meta-data being written. Then the write followed by rename thing would actually be atomic (as we had always assumed it was).
There's a very low performance penalty for using a write barrier. All modern disks support it without having to issue a full flush.
App authors are not demanding that the file date make it to the disk immediately. They're demanding that the file update is atomic. It should preserve the old content or the new but never give us a zero length file.
Can this be that difficult? We do not need a total ordering on all file system requests. We just need it for certain meta-data and content data writes.