Aggregation's $project stage can be either an 'inclusion' projection or an 'exclusion' projection. An exclusion projection is allowed to specify only exclusions of paths, whereas an inclusion projection is allowed to include fields, but also add/replace fields with 'computed' values. We have separate classes to represent/execute these different kinds of projections: ParsedInclusionProjection and ParsedExclusionProjection, which have trees of InclusionNodes and ExclusionNodes respectively.

The oddity of this design is that an InclusionNode is really a hybrid of included and computed paths, and is unable to differentiate between the two. This became a problem when we added the $addFields stage, which strictly adds or replaces fields/paths. Because of the hybrid responsibilities of the InclusionNode, we are unable to take advantage of certain optimizations such as extracting which fields are going to be added/replaced during an $addFields stage. It would also be a lot cleaner and easier to think about if there were three types of nodes corresponding to the three types of transformations possible.