I think it was more likely an emergent effect of rubbish file system and disk cache behaviour, little or no prefetching, etc, than any coordinated activity in SMB?
It's neither an accident nor planned mechanism. It had nothing to do with network, the transmission wasn't switching to multicast.
Probably the author observed that reading different files from disk simultaneously was slower, until the copy process catches up to read the same files.
Seek time on mechanical hard drives sucks, and was much worse back in the prime LAN party days.
System RAM or Drive cache REALLY helped, so yes, the lagging copy would drag down the leading one until they both caught to within that buffer and things zipped along.
Im that case, how does one transfer catch up to the next one? Shouldn't the seek time from switching files have the same impact on both and keep the first one in the lead?
The disk cache is what lets the second one catch up. It would only happen if the copies were started at nearly the same time; soon enough that what's been copied so far is still in the cache.
I've observed this same behavior on modern operating systems with big rsync jobs and spinning drives. If you have lots of small files then reading the metadata and directory structure takes a while but fits in the cache, so a second rsync will catch up very quickly to the first.
