Попробую выдвинуть гипотезу: ручная vtbl уже была в Си, что позволило пропустить первый этап. С корутинами такой халявы не было.

Корутинам уже более 60 лет, давно уже понятно, что это такое и как делается. Так что этот аргумент не катит. Разве что хотели не корутины, а нечто большее

Хотели много контроля, в стиле С++ мне кажется. С возможностью влезть очень глубоко.
Как мне кажется

Делается прототип в нескольких компиляторах, делаются космолёты. По итогам, обсуждается, космолёты улучшаются

Через несколько десятков итераций - принимается в стандарт первый кубик.

Так корутины были запрототипированы Гором в вижаке и в clang, успешно обкатывались в facebook

Предлагаю другую теорию заговора.
За stackless (или stateless) корутины топила Microsoft, насколько я видел по proposals (когда еще с интересом наблюдал за ними). Идея хороша, ввиду отсутствия стека = меньше требования по памяти. У Microsoft, как я понимаю, уже был опыт реализации корутин в C#, как писали выше. Так что по факту взяли эту реализацию за основу. Только пошли не сверху, как положено, а снизу (см. https://t.me/cpprussia/44719).  В результате сейчас в стандарте имеем потроха, но не имеем высокоуровневой реализации. Отсюда и недоумение рядовых потребителей, вроде меня, "как это использовать", а также заклинания комитета "в C++23 все будет немного лучше, а потом еще".
Остается надеяться, что комитет ничего в потрохах не забыл.

Подозреваю, что для разных задач нужны разные stackless короутины. Для обслуживания 100k TCP-подключений посредством Asio — одни. Для написания парсеров — другие. Для HPC и распараллеливания вычислений — третьи.

Все в стандарт не запихнешь.

А чем запихивать то, что будет одинаково плохо справляться сразу со всем (см. на пример iostreams), так лучше уж ограничиться минимальным конструктором. Что, судя по всему, и сделали.

Платой за это становится то, что:

a) многие думают, что если в C++20 включены короутины, то значит эти короутины уже пригодны к повседневному использованию "искаропки";
b) те же, кто пытаются погрузиться в детали стандартизированного конструктора быстро приунывают от его сложности и гибкости.

Наверное, гораздо меньше разочарований было бы, если бы народу объяснили, что в C++20 вошли не короутины, а конструктор для разработки короутин. ИМХО.

Я бы и с другой стороны взглянул: async task - вполне понятная отдельная сущность, которая может быть реализована на корутинах, а может и не быть. Акторы - тоже может быть реализована на корутинах, а может и нет. Все это велосипедят уже лет 20, и в общем-то я не вижу 100% доказательств, что реализации этих сущностей на корутинах будут лучше во всех возможных смыслах. Кто-то готов жертвовать памятью, кто-то нет. В некоторых задачах важны наносекунды, а в других - не важны. Так почему  так зациклились на корутинах?.. Почему комитет нас убеждает, что вот сделали кубики, из которых потом можно делать гениальные вещи. Эти же вещи можно делать и без этих кубиков, из другого набора-конструктора, может, не такого новомодного, но работающего вполне прилично. Читабельность кода?.. Да, это важно, но пока, имея лишь кубики, посторонний наблюдатель может сделать вывод, что читабельность не только не улучшилась, а ухудшилась. Порог вхождения в дивный мир корутин пока что установлен довольно высоким.

В каком-то из объяснений звучал такой аргумент: stackless coroutines без поддержки компилятора толком не сделать. Поэтому добавление таких короутин и пошло через комитет.

Почитывая (перед сном) proposals, я бы сказал более цинично: в комитет тащат все (кто не ленится) и всё. Кстати, недавняя новость про китайские "патчи" линукса (и их бесполезность) ради строчки в резюме и повышения своего реноме - как бы наводит на размышления, откуда это все берется.
А далее - чьи лоббистские усилия победят, с тем нам и жить.

в стандарт вошла "поддержка stackless корутин"

основной плюс корутин в том, что всю сложность их реализации можно вынести отдельно, и дальше уже на этих примитивах писать линейный код, который будет выполняться асинхронно

вот это вот "линейно писать асинхронно выполняющийся код" многого стоит. Например читать код с акторами/фьючами/классическими тредами и прочим очень тяжело не зная фреймворка.

Фокус в том, что нет готовых к использованию короутин в C++20. Будут какие-то короутины из Asio, из HPX, еще из чего-то. И придется читать не C++ код с короутинами, а C++ код на Asio, HPX и еще чем-то. От знания фреймворков никуда не уйдешь.

А с учетом закона протекающих абстракций разработчику еще и желательно будет в потрохах C++ных короутин хоть как-то разбираться.

Так что, наверное, хорошо, что "поддержка" в языке появилось. Но на волшебную пилюлю как-то не тянет. И писать кипятком от восторга нет желания.

Не вижу в этой теории никакого заговора, по-моему так все и было на самом деле, и никто этого не скрывает. При этом я не согласен с выводами, что в C# async/await получился хорошо, а в C++ комитет не доработал корутины. Рассмотрим, что было сделано в C# в рамках async/await:
1. Компиляторная машинерия для обработки await-expressions.
2. Базовый класс Task<T>.
3. Для имеющихся асинхронных API стандартной библиотеки (сокеты, http, thread pools, ...) добавлены перегрузки возвращающие Task<T>.
При этом с классом Task<T> вышла промашка — это не мое мнение, а "architect and lead developer on .NET tasks": "Sadly, by then, .NET’s Task had already been made a class. Since .NET requires async method return types to be Tasks, they cannot be zero-allocation unless you go out of your way to use clumsy patterns like caching singleton Task objects." (http://joeduffyblog.com/2015/11/19/asynchronous-everything/). В C++ такое стандартизовывать нельзя, надо придумать что-то получше.
Дорабатывать асинхронное API стандартной библиотеки в C++ даже не надо, его попросту нету.
Таким образом получается, что из 3-х пунктов сделанных в C# для C++ актуален только 1-ый, и именно он и был сделан.

давайте я еще раз поясню. Как выглядит корутина:

some_async_task<T> doSomeTask(...) {
   // linear user logic
}

Так вот: нам не шибко интересно как реализован some_async_task в таком коде. И нам не шибко интересно как реализован executor на котором потом будет выполняться этот some_async_task.

а линейный код мы всё еще можем писать

>путем мысленных эксперементов
Ну почему же, вполне реальных, тот же cppcoro с корутинами, или libunifex теперь для экзекуторов

я понимаю что собирать из кубиков удобнее. Однако если вы напишете код используя условный cppcoro, есть вероятность, что перевод с него на стандартные корутины в будущем будет не таким уж и проблемным.

1. Да
2. Нет
3. После 2016 не верно. Но там есть оговорки по поводу перегрузок.

Более подробно отвечу когда буду у компьютера

> Так вот: нам не шибко интересно как реализован some_async_task в таком коде.

Как минимум, нам хорошо бы знать, передет ли короутина после ожидания на другой тред или нет.