Updating the atime is in the filesystem code, below the VFS. So opening read-only would not trigger copy-up ... it simple passes through to whichever fs in the stack contained the file (inode) ... and that fs then handles it (or ignores it if noatime was set on that mount.
It's interesting to ask if it's possible to specify noatime on some layers and not on others. I see no reason it shouldn't be possible.
I would hope that the open for read-write or read-only or append would only *mark* the file for copy-up. Any subsequent write() on that file descriptor should trigger the actual copying.
The ugly bits are the -EXDEV (directory renames triggering the need for whole directory copies) and the "whiteout" entries. (I presume the later are technically vnodes ... inode-like structures existing only in the VFS and not written to any of the filesystems in the stack?)
Actually all of this raises interesting questions about different use cases for union file stacking. Should the removal of a file simply be an operation that only affects the top layer? Or should it drill down to all write-able layers in the stack? Should this "whiteout" persist through a umount/mount? How should the system handle cases where we are mounting filesystem in different stacks at different times. The simple use cases where we have one filesystem (CD-ROM, network read-only mount etc) are easy to imagine. Add a "magic" file on the top-level filesystem (like ext2/3's "bad-blocks" and "journals" --- files/inodes with no visible links, or like the .nfsXXXXXXXXX server files we see when files are removed on some NFS clients while still open on others; have this contain the whiteout data and any other semantics).
But what about when we want to use union filesystem stacks as a sort of transparent version control system? (Similar to the infamous MVFS/VOBS from Clearcase and other such systems). It gets messy to even define the desired semantics, much less implement them.