$unionWith is able to push down some stages. Currently only $match and $project, but after SERVER-109212, more stages will be eligible.

Some stages will never be able to be pushed down via SERVER-109212, and will act as a barrier to optimisation. For example, $limit and $sort in the example below:

db.orders.explain().aggregate([  
  { $unionWith: {   
      coll: "oldOrders",   
      pipeline: []
  }},
  {$limit: 10}, // or {$sort: {qty: 1}}
  {$project: {qty: 1}},
])

db.orders.explain().aggregate([  
  { $unionWith: {   
      coll: "oldOrders",   
      pipeline: []
  }},
  {$project: {qty: 1}},
  {$limit: 10}, // or {$sort: {qty: 1}}
])

Only the second example will have the projection pushed down to the find layer. $sort and $limit in principle could swap with $project here.

This could be solved either by changing the rules for rewriting of these stages or by allowing $unionWith to look aheard to std::next(std::next(it)) and reorder if std::next(it) allows it.

NOTE: This ticket does not depend on SERVER-109212, it can be implemented at least for $project as in the example below, but it should probably be implemented with consideration of SERVER-109212.