From CR:

doubly-nested $unionWith and a $lookup + $unionWith combo. To confirm that the view resolution logic works well recursively (when in a nested ExpCtx and everything).

By 'doubly-nested' I mean something like
collA.aggregate([{$unionWith: {coll: "viewA",pipeline: [{$search: {...}},{$unionWith: {coll: "viewB",pipeline: [{$search: {...}}],}},]}}])
 
A similar case which might give us a test of some new combination of invoking the new logic might be:
const viewA = [{$set: {x: 42}}];// create search index on 'viewA'.const viewB = db.createView("collA", [{$unionWith: {coll: "viewB", pipeline: [{$search: {...}}]}}]);// query 'viewB', maybe putting the whole thing inside another $unionWith.
 
I was discussing with Will recently how the batch size tuning only applies to top-level $searches and I just want to avoid a case where we have something stuck into 'runAggregate' which is needed to work correctly and is not present in the sub-pipeline codepath (think 'attachCursorSource' and friends). This patch doesn't introduce anything in 'runAggregate', but I'm worried about whether any of the code already added there for views would need to be copied over or factored out to here.