From a comment:

// Sadly, in some cases the match details cannot be generated from the unoptimized
// MatchExpression. For example, a rooted-$or of equalities won't work to produce the
// details, but if you optimize that query to an $in, it will work. If we were starting
// from scratch, we may disallow this. But it has already been released as working so we
// will keep it so, and here have to re-parse the projection using the new, normalized
// MatchExpression, before we save this projection for later execution.

During code review, we thought:

charlie.swanson@mongodb.com: This is troublesome. I welcome other suggestions but this was the best I could think of. Always re-parsing seems like it would defeat the purpose. Another option I considered was to just use the optimized MatchExpression for the query shape for positional projections, but that's a strange edge case that would then become user-visible

davis.haupt@mongodb.com: I'd be curious to see if we can measure the perf impact of this. My first guess would be that parsing projections isn't that expensive relative to filters, but that intuition may be wrong.

jacob.evans@mongodb.com: what are the details? the bit that interacts with positional projection? I'm tempted to leave this and file a ticket to make it so that requiresMatchDetails() can't silently fail with certain inputs, we should probably check with the stakeholders (thinking Andy) to make sure it's okay to make this type of query slower, I think it's worth asking since this doesn't seem like our bread and butter... and we might want to add a workload if one doesn't exist...

For this ticket, we should see the performance impact in two cases:

1. If we always double-parse can we measure anything actually getting slower?
2. Do we have any benchmarks with positional projections? Can we test the impact on avoiding this double-parse there? Do we need to create new benchmarks to test it? For this testing, it is probably acceptable to have the one-and-only projection parse use the optimized MatchExpression, even if that means temporarily changing the query shape for such queries.