Currently, each FETCH stage within a query plan opens its own storage-level cursor for accessing the collection:

https://github.com/mongodb/mongo/blob/bdf6af1e48db8cb4a21e821068af4cc2faac7415/src/mongo/db/exec/fetch.cpp#L105-L106

For plans with many FETCH stages (e.g. a large indexed $or), this means that a single query can open many storage-level cursors. Having many storage cursors open at one time can be expensive. This can be easily avoided in the query layer by making a PlanExecutor's execution stages share a single RecordCursor. (If the plan is covered, it never accesses the collection, so the PlanExecutor will open zero RecordCursors rather than exactly one.)

This optimization is only valid for PlanExecutor instances which operate over a single collection. PlanExecutors which may involve several collections, i.e. those for aggregates involving more than one collection, will not open a shared RecordCursor.