In the case where the best candidate plan reaches EOF once during the trial we see the following:
When we call doWork() on the MultiPlanStage in normal execution, it first drains any buffered results and then calls work() on the candidate again, observing EOF a second time. Both EOF probes increment the child plan’s works counter, even though no extra keys or documents are examined.

We should be able to track whether or not we hit EOF in the trial phase and/or re-use existing functions such as MultiPlanStage::isEOF() to avoid unnecessarily calling work() in this scenario.