Assuming the file is replaced (same name) wholesale and not modified in-place (i.e. create a temp and then rename to filename).
I imagine the change would not affect a local mmap since the kernel still has a handle to the old file (inode) on disk.
However, since NFS is stateless, would the mmap get all confused and mix up the old/new file contents during the (long) lifetime of the mmap?
It seems to me read/readv is the only safe way to process NFS-mounted files.
If you have an open reference to a file, that reference will continue to refer to the same file for as long as the reference lives, even if the file itself is deleted or renamed and even if its name is reused by a brand new file after it is deleted. The reference can be a file descriptor or a memory mapping. This is part of POSIX and it's true (or should be!) no matter what type of filesystem is in use.
In other words: if you open a file on an NFS filesystem and map it into memory, you can continue to use that memory mapping for as long as you don't unmap it, even if some other process (or the same process) deletes the file and replaces it with a new one with the same name.
It's true that the NFS protocol is stateless, so the implementation has to take special steps to make sure this case is handled correctly. It's been a very long time since I looked at how it's done, but the last time I did (on Solaris), it was done by renaming files to special hidden names (.nfsXXXXX) instead of deleting them if their link count was decremented to zero while there were still open references to them. Anyway, whatever trick is used by the implementation, you as the user of the filesystem shouldn't have to worry about it.