Hi @mikependon,
Reading through the code, I noticed that the Conjunction, Operation and Order enums are all defined as shorts, and I'm puzzled about why this is - presumably it's to reduce memory usage at runtime, but in that case why not use byte (or ushort)? I suspect that values smaller than int are padded and aligned to a 32-bit boundary anyway, so I'm not sure this actually makes much difference in practice.

This in itself isn't a big problem, but I wonder if there's maybe an alternative optimisation available in this area? If these enum types were instead defined as int (as is the default), and each of their values declared as a pre-determined hash value (or at least, something random-ish, non-consecutive and non-colliding), then there would be no need to call GetHashCode() on these any of these types at runtime - you could simply use the enum's underlying value instead - effectively a no-op.

I haven't tested or benchmarked this, and don't know the codebase well enough to judge whether this approach would provide any meaningful gains. It may be worth considering though, particularly if the hashes are calculated within any performance-critical code paths.

It's also possible that the compiler is already smart enough to pre-calculate the hash values at build time - again, some digging would be required to confirm whether this is the case.