I'm of the same mindset. I mean -- surely there are some collisions always. And I actually liked the property of the original version that a zero value hashed to all zeroes. While the rest of the pre-image was shuffled. But I suppose that being able to compute collisions is not a great thing. You may think that if it is not intended to be used in a cryptographic sense it does not matter. However, if you can easily compute collisions you could, theoretically of course, launch a denial-of-service attacks on a service (cache denial) by sending lots of values to the same hash slot. I mean, with probing and so on there are ways around this and in the end maybe the conventional wisdom ought to be revised, maybe there isn't so much to worry about from a few collisions, even easy to compute ones. But, as it stands, right now, the market demands collision resistance. So I damn well gave it to them.

[keep in mind I'm far from an expert on this]

The thing that bothers me personally about these examples is that there are a lot that end in 0x000000 or 0xffffff, i.e. all bits set or all bits unset in many of the trailing bits.

If you use this for a hash table, a common way that you get your index into the table is:

    index = hash_result % table_size

If you use power-of-two table sizes, then you are going to get these collisions, even though the upper bits differ.

You can use a non-power-of-two table size to compensate for this (prime sizes are typically the most robust choice I think) at the cost of a more expensive modulo operation. See more here in the first section: https://en.wikipedia.org/wiki/Hash_table#Hashing