Before $unionWith was implemented, all DocumentSource derived classes followed the same implementation pattern for "executionStats" or ""allPlansExecution" verbosity explain operations. Namely, the explain is done in two phases:

• First, the pipeline is fully executed and the resulting data discarded. That happens here. During execution, runtime stats are captured and stored inside the stages of the pipeline.
• Second, Pipeline::writeExplainOps() is called. This is intended to serialize the pipeline and its runtime stats without actually doing any further query execution.

$unionWith, however, does not work as described above. Rather than serializing its original subpipeline during DocumentSourceUnionWith::serialize() it issues an entirely new explain operation related to the subpipeline which may do further query execution. This goes against the typical design for aggregation explain and requires some special infrastructure in the MongoProcessInterface. It may have some benefit in that we are able to provide more detailed explain output in the case that the collection on the inner side is sharded. However, it seems worth at least looking into whether we can reimplement explain for $unionWith to avoid this complexity.