Generally not - the xfsprogs cache indexes read blocks by offset and
I/O size. It will generate this warning if it encounters a read to the
same offset with different I/O size. Basically there to tell me that
there's a scenario where this may happen and should be fixed.

2) Why did xfs_repair -n after I ran xfs_repair yield yet another
error "would have reset inode 94530 nlinks from 2 to 3"? Why didn't it
appear in the first pass?

There are remote cases where the first pass does not get the nlinks
quite right - I would have needed a metadump before the first run to
isolate where it miscounted the nlinks. All problems like this in
the past have been related to lost+found.