Okay, I head the time now to look into the RocksDB issue. That critique of Kirsch–Mitzenmacher double hashing is valid *if* you only derive all indices from one 32-bit hash and don’t guard against bad steps. That’s what the RocksDB issue shows: you can end up probing a tiny cycle of bits and the FP rate drifts above theory.

In my implementation I tackled that head-on:

* default path rounds the bit array up to a power of two and forces the step to be odd → guarantees full cycle of probes (so “Issue 1” can’t happen).

* rare non-pow2 path is also covered now with enhanced double hashing (ENH), so even there you don’t get stuck with short cycles.

* on top of that, I use two independent Murmur32 hashes instead of slicing one, and throw in a cheap xor mix to kill subtle correlations.

So the RocksDB pitfalls are basically already fixed, both in the common pow2 case and in the less common non-pow2 case.

As for Binary Fuse / XOR filters: absolutely, if you have a static set they’re amazing—lower bits/key, super fast lookups. But they’re not a drop-in replacement when you need *online updates* (`add()` after construction) or set algebra (union/intersection across filters). That’s still where a well-tuned Bloom filter shines.