Thanks for the link++. I was aware that the seed value had been randomized so that the binary hash value would therefore be randomized, but I didn't know any details about "Hash Traversal Randomization". Evidently when a collision occurs, lengthening the hash bucket's list, can cause/most likely will cause a significant difference in the order that bucket's list is returned when traversed *even if the number of hash buckets did not increase*. I wasn't sure if that order was "stable", but evidently it is as long as the hash is not modified. Of course all of this implies that if a deletion occurs, that can also change the order of presentation (which was not true before 5.18).

values "line up" just means that key=>value correspondence between the horizontal presentation using values and keys vs the vertical presentation using each are the same.

Update:
I'll make some comments about Perl hash performance upon hash insert. A long time ago, I was working with what I thought were "big" hashes, 100-200K keys. An initial Perl hash array starts as a C array of pointers to lists, where the array size is 8. As the hash grows due to inserts, according to an algorithm, Perl's C array of pointers to lists (the number of hash "buckets") will double in size when Perl figures that is "the right thing to do"... 8,16,32,64,128,256,512,1024,2048... There is a lot of calculating that happens when the number of hash buckets doubles. There is a way to start out a Perl hash with a specified number of "buckets". I found out via a lot of benchmarking that didn't matter much. The C code that doubles the number of hash buckets runs very efficiently compared to my user Perl code that uses the hash. My conclusion is that Perl hashes work very, very well.