Given a link to a file at path A exists. The file contains data X. There may be other links at paths C, D and E.
1. Acquire a filesystem-global lock on link ops (link/unlink et al, but not read/write).
2. Create a link to X at path B
3. Remove the link at path A
4. Release the filesystem-global lock.
Note: The data in X is not relevant. The data in X may be undergoing active modification while the above 4 steps are performed. The data in X may be memory mapped and may change many times during the "atomic" rename() syscall.
The atomic properties of rename() are only vis a vis link/unlink semantics within a single filesystem. Other files can't be created or deleted while the rename() is in progress. File data however is under no such restriction -- and in fact it cannot be because the file may be memory-mapped and modified without any syscall interactions. There is no system call sequence point to gate reads and writes.
What you are describing is fundamentally incompatible with how the system actually works. What you describe cannot be made to work, ever. It is architecturally invalid at a fundamental level.