'softupdates' is proof of the complexity of keeping two fully generalized
versions of the meta data around at all times - not only that but
converting back and forth between the two versions on demand.
You can't really "queue" a rename, without doing something comparable to
what softupdates does, because the rename has to take immediate affect from
the application perspective. To do that, somewhere there must be a layer
to keep track of the difference between what the user visible meta data is,
and what the committed meta data is. If the differences are sufficiently
general, that is a major problem. If one wants high performance rename
replacements, rename undo is much more practical.
It would be practical to update atimes on a low priority basis, with the
caveat that a lot of memory may be consumed holding metadata blocks around
until the atime updates are complete. In addition, on a system under
sufficient load, moving I/O to a low priority thread doesn't really help