There are a number of operators (for example, $mod, $regex, $geoWithin) that are hard-coded as edge cases for being incompatible use btree index negation. When given a query of the form {$not: <leaf>} with one of those operators at the leaf, the root MatchExpression is not tagged as compatible with a btree index on the relevant field.

In many cases, $not queries are parsed into the form {$not: {$and: <>}}, but if there is only one predicate under the $and, the $and is optimized away. However, if the un-optimized, valid query ({$not: {$and: <leaf>}}, with one of the leaf examples from above) is passed to rateIndices, it instead recurses down the logical not-and chain here, and marks the leaf node as being compatible with a btree index on the relevant field.

This isn't a problem with running a query end-to-end since the PlanEnumerator does not generate any plans for a $not-$and query, so it falls back to collection scan, but it is misleading that the equivalent {$not:{$and: <leaf>}} and {$not: <leaf>} queries are tagged differently within rateIndices.