The perlsec passage to which you linked says the order shouldn't be assumed to be random. The perlrun passage to which you link doesn't explicitly mention changing key orderings at all. It is not the purpose of the feature to alter the key ordering, much less making it random.

Two problems with your assumption:

• The feature in question only kicks in when needed.

• Even if you could reliably trigger the feature, it's purpose is to salt the hashing algorithm (i.e. perturb bucket selection). While this has the side effect of affecting key ordering, it hasn't been shown to produce random key orderings.

But enough theory. Let's look at a practical example:

for (1..100) {
   my %h;
   $h{$_} = 1 for 'a'..'z';
   print(join('', keys(%h)), "\n");
}
[download]

wraxdjyukhgftienvmslcpqbzo
wraxdjyukhgftienvmslpcqbzo
wraxdjyukhgftienvmslpcqbzo
wraxdjyukhgftienvmslpcqbzo
wraxdjyukhgftienvmslpcqbzo
wraxdjyukhgftienvmslpcqbzo
...
wraxdjyukhgftienvmslpcqbzo
wraxdjyukhgftienvmslpcqbzo
[download]

And the same if I run the program again.

A simple question: Are the results of your example predictable for any combination of hash keys without knowing the hash seed?

Yes.

Without knowing the seed or the hashing algorithm, I correctly predicted 99% of the results the first time I ran the program, and I correctly predicted 100% results the second time I ran the program.

The hash was never reseeded since the pathological case was never encountered.

In a more casual sense, the order is unpredictable. It just hasn't been shown to be random. Even if the hash had been reseeded.