> Also in the write/sync/rename workflow, what happens if the temp file is on a separate filesystem?
In the write/sync/rename workflow, this is never supposed to occur. The temp file must always be on the same filesystem as the real file for the atomic-rename guarantee to apply.
Naturally, this can be extremely difficult to achieve in some cases. The file may be a symlink, which must be fully resolved to a symlink-free path to determine the real filesystem. The file may be the target of a bind mount, in which case I doubt there is any portable way to determine which filesystem it came from. And there there's the possibility that you can write to the file, but not the directory _containing_ the file...
The write/sync/rename process is hardly an ideal way to implement atomic replacement semantics. There are simply too many potential points of failure.