ElemMatch

Some single element at path satisfies operand, whose paths are relative to that element.

{"items":[{"sku":"A","qty":1},{"sku":"B","qty":5}]}

and(     $.items[*].sku eq "A",  $.items[*].qty eq 5)    matches — different elements
elemMatch($.items[*], and($.sku eq "A", $.qty eq 5))     does not

The paths inside are relative, and that is the whole of the type discipline here. path names the elements — a CatalogPath ending in [*], ordinarily — and every path in operand is read from an element as if it were the document. $.sku inside means the element's sku, never the document's. Nesting is therefore ordinary: an ElemMatch inside an ElemMatch walks two levels of elements, and each level's paths are relative to its own.

Existential over elements, and negated at the document like every other leaf. not(elemMatch(…)) holds for a document where no element satisfies the operand — including one with no elements at all, and one whose items is a string. It is not "some element fails it"; the same rule, and the same reason, as Not over a Compare.

What it costs, and what makes it worth asking for. Without an index this is a walk of each element per document, which is what a caller was writing by hand anyway. With a IndexKind.COMPOSITE_TERM index over path declaring exactly the fields the operand compares, it is one dictionary lookup and the answer is exact — no recheck, no document opened. The measurement that justified building that index is the gap this node closes: over corpora whose element fields vary independently the uncorrelated conjunction returns 5-6x the documents a caller keeps.