This reminds me of Allocate On Flush. When a filesystem uses this feature, instead of writing data directly to disk, it subtracts the size of the data to be written from the disk's free space counter, and holds the data in memory until it a sync system call is performed or the kernel decides to flush the dirty buffers.
In this case, if the file is being modified by one process, and gets opened by another process, the latter process will "see" the unmodified (or "old" if you prefer) version of the file.
Of course, the above are theoretical and depend on various factors, and I'd say a bit unpredictable -since you don't know exactly when the kernel is going flush the dirty pages. For instance in Linux (as you can also read in section 15.3 of Understanding the Linux Kernel), the dirty pages get written to disk under the following conditions:
The page cache gets too full and more pages are needed, or the number of dirty pages becomes too large.
Too much time has elapsed since a page has stayed dirty.
A process requests all pending changes of a block device or of a particular file to be flushed; it does this by invoking a sync(), fsync(), or fdatasync() system call.
This feature is known to be implemented in HFS+, XFS, Reiser4, ZFS, Btrfs and ext4 filesystems.