This would be similar to the failpoint implemented in SERVER-35891, but would be for consumption by users rather than for internal testing purposes. On any given aggregate command, the application could specify a hint to disable optimization of the aggregate pipeline:

db.collection.aggregate([<pipeline>], {disablePipelineOptimizations: true})

Internally, this would work like the failpoint from SERVER-35891 and would convert Pipeline::optimizePipeline() into a no-op. The effect would to be to prevent rewrite optimizations like $match pushdown and $sort-$limit coalescing into a top-k sort. It would serve as an "escape hatch" in the cases where an optimization is actually unhelpful, putting customers into a mode where their pipeline is much closer to procedural code than a logical statement of the query.