We currently document that renaming is not supported because of posix guarantees on atomicity that we can't meet. I wrote this mistakenly thinking that the guarantee when doing rename(old, new) was that old is deleted atomically with new being created.

But this doesn't make any sense when multiple mount points are involved—it would probably be impossible to implement. More importantly, this is not actually what posix requires. The documentation on rename says only:

If the link named by the new argument exists, it shall be removed and old renamed to new. In this case, a link named new shall remain visible to other processes throughout the renaming operation and refer either to the file referred to by new or old before the operation began.

And similarly for directories. The Linux man page for rename(2) even says:

when overwriting there will probably be a window in which both oldpath and newpath refer to the file being renamed.

So I was definitely wrong about the requirement—in reality it's only about renaming being atomic from the perspective of new. We can support this for files (but not directories), and it's very useful for cases like that discussed in #77. So let's do so.