SERVER-84338 disabled the MatchExpression $or->$in rewrite when the equality predicates are parameters. For example (in pseudo-MQL), {$or: [

, {foo: p2}]} cannot be rewritten to {foo: {$in: [p1, p2]}} because InMatchExpression only allows the entire $in operand to be a single parameter. This fixed an edge case in the subplanner which resulted in construction of a residual predicate with incorrect autoparameterization behavior.

Another solution to that problem is to introduce a new MatchExpression or modify the representation of InMatchExpression parameters in order to allow an InMatchExpression to contain an array of parameters and literals.

Some questions we'd need to answer to do this ticket:

• Is the subplanner case in SERVER-84338 the only one where an array of parameters in $in would occur?
• If so, is the complexity added by implementing this ticket worth the potential performance gain?