In AsyncWorkScheduler::scheduleRemoteCommand's remote path (_targetHostAsync(...).then(...)), the targeting handle is drained before the .then continuation registers the command handle. In that gap the scheduler looks idle (_quiesced() is transiently true), so a waiting join() returns and the owner can destroy the scheduler while the .then continuation still holds a raw this, causing a use-after-free. This is a flaw in AsyncWorkScheduler's teardown bookkeeping, not in the executor's TaskExecutor::scheduleRemoteCommand primitive.

Only Windows debug builds crash on it, via the iterator check that fired the reported assertion. On Linux the bad access is silent unless built with ASAN.