The query idhack path (a performance optimization to reduce planning/execution overhead for operations with query predicates of the form {_id: <value>}) is currently supported by a plethora of special cases in the query execution path:

• The CanonicalQuery::isSimpleIdQuery() method.
• Logic in ParsedUpdate and ParsedDelete to skip canonicalization for idhack queries (and a method for the caller to force re-canonicalization for the case in which the id index is not present).
• Logic in prepareExecution(), getExecutor(), getExecutorUpdate(), getExecutorDelete() to skip query planning for idhack queries and force manual stage tree construction.
• The IDHackStage query execution stage (which includes, among other things, duplicated logic to handle the case where the document to be fetched is not in resident memory), and explain functionality for this stage.
• Logic in PlanExecutor and elsewhere to handle the special case where CanonicalQuery is NULL.

This can be vastly simplified without incurring a significant performance penalty to these operations.

Instead of custom execution machinery, idhack queries should have custom planning machinery. The query planner can fast-track a single query solution for idhack queries (FETCH <= IXSCAN, with an optional projection), and custom logic can be added to the index scan stage to avoid use of the "end checker" for point queries against unique indexes (which is a performance win for all queries including an equality expression against a unique-indexed field, not just idhack queries).