Unifying filesystems with union mounts

if a layer is read-only then atime should not be updated on it. the definition of union mounts is that all layers except the top one will be read-only (which avoids the headache you mention of deciding which writable layer to modify)

which either means that atime is implicitly disabled by union mounts, or the upper layer needs to store it.

I don't see how directory renames are any worse than large files that get renamed or small modifications (think logfiles for example), in both cases you have a (potentially large) disk item that needs to get copied (after all a directory is just a 'file' containing pointers to file contents). or are you saying that if a directory gets renamed all the files in that directory get copied? if so then the layering also is incompatible with hard linked files.

the other option is to extend the whiteout concept to provide a 'link' type entry as well (similar to a symlink, when file X is opened on the top layer, open file Y on lower layers)

the whiteouts (and any other modifications) definantly need to persist across mounts, otherwise the result can't be considered coherent. now if you remount with a different combination of things (or modify the underlying filesystem(s) through some other mechanism) things do get interesting.

if you want version control semantics then you probably want to use FUSE, not union mounts. if you used union mounts then for each new version you would mount another 'filesystem' on top of the stack, and each version could be accessed (read only) by other processes by mounting the appropiate layers of the stack.

the issues that you would run into here would just be efficiancy in drilling down through (potentially) many layers of the stack.

but that does bring up a question, how can you query what the stack is? If many layers have been mounted over time it may not be trivial to know how to recreate the stack for the next boot if you can't query the kernel to find out.