When a query projects multiple paths, the ColumnScanStage calls addCellToObject and/or readParentsIntoObject with different paths on the same output object.

In at least one place, these object materialization functions assume that they will not be used for multiple paths when one path is not a subset of another.

Counterexample
Document:

{a: [{n: 1, m: 2}, {m: 1, o: 2}]}

with projection:

{_id: 0, "a.n": 1, "a.m": 1}

ColumnScanStage proceeds alphabetically, first calling addCellToObject to materialize a.m, resulting in:

{ a: [ { m: 2.0 }, { m: 1.0 } ] }

Projection then continues to a.m. Because a.m is sparse, there is a call to readParentsIntoObject for the a component. This call overwrites the existing object children of the a array with empty objects:

{ a: [ {}, {} ] }

The final output of the projection is:

{a : [{n : 1 }, {}]}

The correct output would be:

{a: [{n: 1, m: 2 }, {m : 1 }]}