The following example aggregation operation reports explainVersion:"2", indicating that the portion of the query pushed down to the find layer is executing using the SBE engine:

MongoDB Enterprise > db.c.explain().aggregate([{$match: {a: 1}}, {$unwind: "$b"}, {$project: {_id: 0, a: 1, b: 1}}]).explainVersion
2

However, if I modify this aggregate command just slightly to include a $dateToString expression, then the portion of the query pushed down to the find layer falls back to the classic execution engine. This is indicated by explainVersion:"1" in the following example:

MongoDB Enterprise > db.c.explain().aggregate([{$match: {a: 1}}, {$unwind: "$b"}, {$project: {_id: 0, a: 1, b: {$dateToString: {date: "$b"}}}}]).explainVersion
1

Note that the $dateToString expression itself is executing in the DocumentSource layer, since it is not pushed down into $cursor:

MongoDB Enterprise > db.c.explain().aggregate([{$match: {a: 1}}, {$unwind: "$b"}, {$project: {_id: 0, a: 1, b: {$dateToString: {date: "$b"}}}}]).stages
[
	{
		"$cursor" : { ... }
	},
	{
		"$unwind" : {
			"path" : "$b"
		}
	},
	{
		"$project" : {
			"a" : true,
			"b" : {
				"$dateToString" : {
					"date" : "$b"
				}
			},
			"_id" : false
		}
	}
]

Because the $dateToString operation is not pushed down, the $cursor portion of this query is fully supported in SBE. As an improvement, we should change the logic which chooses between the SBE and classic engines so that it allows the SBE engine to be used in scenarios like this.

It looks like the reason for the current behavior is that the value of ExpressionContext::sbeCompatible is set at parse time, before any analysis is done that would determine which part of the query should be implemented by the find subsystem and which part by the agg subsystem.