Your very first post on this topic made an unevidenced assertion that the hash-related security fixes done in 5.18.0 were both unnecessary and may have significantly slowed the perl interpreter.

No. I offered the possibility that one of the differences visible from the scant information provided, was that the different hashing algorithm might be responsible for the slowdown. Eg, It might be that the OPs data invoked a pathological behaviour with the new algorithm, but not with the old.

Given it is a simple recompile to verify one way or the other, why wouldn't he check.

I also mentioned in passing that (IMO) the change of algorithm was unnecessary. No assertion; just my opinion. An opinion that you have said nothing to change.

It's inflammatory because you've taken a in-passing expression of my opinion, and made a mountain out of a molehill. Deliberately inflaming a thread with a discussion that has no benefit to the OP nor merit to this place.

That's utterly trivial. You send a HTTP request to the server with a bunch of headers or parameters containing the generated keys.

You might just as well send a request that contains a 100 billion headers.

Or you could supply some JSON to a server that processes JSON input.

To the same perl process that supplied you with the headers. Hm.

Think of a spam filter that reads an email's headers into a hash for one hypothetical example of many

So how does the attacker persuade the spam filter to give him an unsorted set of hash keys in order that he can find the seed to generate the headers?

The biggie was that if you supplied a suitable small set of keys in a request (no need to know the server's seed) you could force the perl process to allocate Gb's worth of memory.

Care to supply me with a suitable set of keys such that I can test that assertion? Because outside of this (new to me) claim, you've still to present a realistic scenario for an exploit.