It's atomic but it might not be persistent in the event of a crash. If the metadata wasn't committed then upon remounting the old file might reappear, and its likelihood of reappearing is independent of any other operations on that filesystem. Though, traditionally rename was not only atomic but also preferentially ordered ahead of other metadata operations so subsequent renames of other files wouldn't be visible if the older rename appeared.
EDIT: Actually, I think the issue I had in mind was that writes to the new file might not be committed before the rename, so if you do open + write + rename + close, on a crash the rename might persist even though the write didn't. You technical should use fdatasync if you want the write + rename to be ordered. See, e.g., https://lwn.net/Articles/322823/ But this is such unintuitive behavior that I think that even for ext4 the more reliable behavior is still the default.
Yes. But traditionally Unix filesystems provided stronger consistency guarantees than required by POSIX, and applications have come to rely on them. Actually, in the event of a crash I think POSIX specifies implementation-defined behavior even for fsync.
Making fsync a no-op and not having any durability at all is perfectly POSIX compliant. POSIX only concerns itself with the visibility of I/O in the live system (e.g. a process either sees a write fully realized, or not at all - this didn't use to be true for larger writes until fairly recently, btw.). POSIX specifies nothing about what happens when a system is restarted or looses power.
The dance can get even more complicated[0] if you also want to ensure that the rename itself is persisted. But you only really have to encode this in an atomic-file-write-with-callback library once.
EDIT: Actually, I think the issue I had in mind was that writes to the new file might not be committed before the rename, so if you do open + write + rename + close, on a crash the rename might persist even though the write didn't. You technical should use fdatasync if you want the write + rename to be ordered. See, e.g., https://lwn.net/Articles/322823/ But this is such unintuitive behavior that I think that even for ext4 the more reliable behavior is still the default.