Consider a non-multikey index on {a: 1} and the query {a: {b: 123{}}. We might end up with a SargableNode with requirements PathGet [a] PathGet [b] PathIdentity [] = 123. We will consider a plan which does an IXSCAN + SEEK, with no bounds on 

. However, because we know the predicate in the query implies that a is an object, we can actually produce tighter bounds on the IXSCAN [{}, []] over a. See BSON sort ordering.

The purpose of this ticket is to explore whether we can achieve these tighter index bounds. One solution could add a rewrite that adds (perfOnly?) partial schema requirements to SargableNodes on fields which are implied by existing requirements. Another options could be to modify the index bounds generation to take into account these types.

Another area to think about is if we can do a similar transformation for multikey indexes (PathGet[a] PathTraverse[1] PathGet[b] PathIdentity[])?