As described in SERVER-36393 there are cases where we fail to enumerate some interesting plans because we limit the number of plans we generate for a contained $or. While not a complete solution, one suggestion for a workaround on that ticket was to add a way to enumerate the children of the $or in a different "more interesting" order. To quote:

Asya points out that our plan enumeration code might fall over like this less if it changes its enumeration strategy from something like:
A, A, A
A, A, B
A, A, C
...
To something like
A, A, A
B, B, B
C, C, C
...
This is a heuristic that might help us to force the plan selection code to consider the best index in more cases, short of a more complete solution.

This ticket tracks the work to implement that solution.