Boost Asio: исполнители в сопрограммах C++20

Экспериментируя с boost::asio::awaitable и Executor, я продолжаю наблюдать довольно запутанное поведение, которое мне хотелось бы лучше понять.

Подготовка

Пожалуйста, обратите внимание на следующую программу:

int main(int argc, char const* args[])
{
    boost::asio::io_context ioc;
    auto spawn_strand = boost::asio::make_strand(ioc);

    boost::asio::co_spawn(spawn_strand,
        [&]() -> boost::asio::awaitable<void>
        {
            auto switch_strand = boost::asio::make_strand(ioc);
            co_await boost::asio::post(switch_strand, // (*)
                boost::asio::bind_executor(switch_strand, boost::asio::use_awaitable));

            boost::asio::post(spawn_strand, [](){
                std::cout << "calling handler\n";
            });

            std::this_thread::sleep_for(std::chrono::seconds(3));
            std::cout << "waking up\n";
        },
        boost::asio::detached);

    std::jthread threads[3]; // provide enough threads to serve strands in parallel
    for (auto& thread : threads)
        thread = std::jthread{ [&]() { ioc.run(); }};
}

Как и ожидалось, эта программа выводит:

calling handler
waking up

В частности, "calling handler" печатается перед "waking up", поскольку после строки (*) сопрограмма больше не запускается spawn_strand. Таким образом, последний не будет заблокирован sleep_for и сможет немедленно запустить обработчик.

Пока всё хорошо, теперь давайте раскроем кое-какое запутанное поведение...

Наблюдения

1. Оказывается, что asserting spawn_strand == co_await boost::asio::this_coro::executor после строки (*) не дает сбоя. Мы могли бы предположить, что в этот момент исполнение переключилось на switch_strand и на самом деле просто подтвердило этот факт. Поэтому на данный момент я ожидаю, что co_await boost::asio::this_coro::executor будет сравниваться с switch_strand вместо spawn_strand.

2. Если в строке (*) мы заменим переданную в post цепочку на spawn_strand, результат изменится на:

   waking up
   calling handler
   

   Я читал другие ответы (например, this или this) относительно исполнителей, предоставляемых post и bind_executor, и обычно они предполагают, что первый служит простым запасным вариантом на случай, если у обработчика нет связанного обработчика. Это не соответствует наблюдаемому результату.

3. Теперь давайте возьмем изменение предыдущего абзаца и добавим

   boost::asio::post(switch_strand, [](){
       std::cout << "calling handler\n";
   });
   

   после строки (*). Обратите внимание, что на этот раз мы используем switch_strand вместо spawn_strand. Мы получим следующий результат

   waking up
   calling handler
   calling handler
   

   Это предполагает, что оба обработчика (как на switch_strand, так и на spawn_strand) заблокированы одним sleep_for. В конечном итоге кажется, что после строки (*) сопрограмма запускается на обеих цепочках одновременно, что очень раздражает.

4. Пункты 2 и 3 одинаково применимы, когда вместо замены стойки, переданной на post, мы заменяем нить, переданную на bind_handler, на spawn_strand.

Вопрос

Как можно объяснить эти странные наблюдения? Мне кажется, что в дополнение к обычному функционированию исполнителей по вызову обработчиков, boost::asio::awaitable связаны с дополнительным исполнителем (а именно тем, который предоставляется co_spawn и доступен через this_coro::executor), постоянно присутствующим во время выполнения сопрограммы. Однако я нигде не нашел объяснений этого; ни документации по поддержке сопрограмм Boost.Asio C++20, ни ответов на связанные вопросы здесь. Поэтому я не верю, что на самом деле все работает именно так.