It has been reported to the Service Architecture team that destructor ordering of continuation chains is not well-understood among server developers. This has come up in Slack and issues have been logged:

SERVER-53538 - Clarify semantics of when destructor runs for ExecutorFuture chains
SERVER-54119 - Destroy SharedStateBase as we unfold continuations
SERVER-52942 - Evaluate whether we could change the destruction order of the closure in the ExecutorFuture class

After some investigation, we’ve determined that the semantics around when continuation lambdas get destroyed are difficult to predict. This is mainly because the current implementation does not explicitly define a point at which the user-provided function is no longer held. Our current understanding is represented by the matrix below. It represents the known combinations of conditions that can impact the way that continuation functions run, and hence the multiple code paths that can lead to different destructor orderings:

This issue encompasses the entirety of the work involved in moving to guaranteed destructor semantics.

1. Implement both behaviors using a template argument in the implementation details. (SERVER-66128)
2. Write up a doc explaining destructor semantics and provide direction to Server contributors for upcoming work. (SERVER-66129)
3. Uglify all code to employ a LegacyDestructorOrdering tag on all continuations, and delegate some Jira tickets. (SERVER-66127)
4. Wait for teams to address issues. (bugs pending)
5. Remove tags and remove the legacy delete ordering semantics. (this SERVER-66126)

This task can be closed with the completion of step 5.