The validity of $facet sub-pipelines is checked via the constraints() function, which is implemented for each document source. When computing the constraints of a stage, the function takes into account the constraints in the stage's sub-stages. As a consequence if a stage is not allowed in $facet, we cannot distinguish between the stage not allowed itself and the stage not allowed due to some sub-stage. It seems useful to have explicit information about stages that are directly not allowed in $facet. This information is currently spread among the constraints() implementations of document sources. Consider an improvement where we have this info in one place, but in a way that does not create discrepancies when new sources are added to the system.

Some ideas from the PR of SERVER-80456:

• Keep it where individual stages compute their own facet requirements, but then have a static method (or even member) on DocumentSourceFacet that declares all of the 'not allowed' stages. To avoid discrepancies between the two, you can imagine adding a tassert (or even dassert) somewhere (maybe inDSFacet::constraints) that asserts that the answer is the same for both the DSFacet static method and the individual stage. This is a bit sketchy because we're relying on a tassert for this information to go out of sync.
• Take the above a step further, and move the facet requirements from individual stages to DSFacet (that is, if a particular stage wants to figure out whether it is allowed in $facet, it has to call a static method on DSFacet). This would make it so that the information is in one place, but arguably it's bad design to have a stage depend on another to figure out some state about itself. Also, care would need to be taken to make sure that people in the future add new constraints to DSFacet, and not individual stages