We introduced hashed indexes in 2.4, where we could take an option seed to compute the hash and it worked accordingly. Since 2.6, we computed the hashes for the keystrings using the non-default seed as expected, but when running the query we incorrectly used the default hash key. (The code hasn’t been really changed and here’s the link to them on master: insert, query) Starting from 3.4, we disallowed users to pass the seed option. This option would never be touched throughout upgrades. After 5.0, it will be automatically skipped when calling listIndexes. The validate command can detect this disallowed field on disk, and users can use collMod to remove it from the catalog. Also, it doesn't seem to have any documentation of the seed field, not even on 2.4 where we introduced it.

Since we haven't really got any complaints from our users, I'm not sure if we would want to implement any fix at all to make the non-default seeded indexes to work correctly. On the other hand, we may want to consider removing the code handling the non-default seed on master.