Так быть не должно, это противоречит идее асинхронности

Ну вот мы запустили корутину и продолжаем выполняться. Нужен longjump чтобы вернуться, но мы же его не пишем сами. Кто (и в какой момент) его аызывает/реализует?

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

Бэкенд там очень простой, вот на примере ucontext небольшая демка: https://gist.github.com/DanGe42/7148946
В этом примере используются системные сигналы для прерывания сисколов и переключения контекста, но в самом простом случае достаточно одного swapcontext, он все и делает.

Вопрос был "кто (и в какой момент)", а не "как" - это действительно технические подробности второго плана. Судя по этому примеру

C++ (Qt)
        while (true) {
            qDebug() << "entering loop";
            co_await qtcoro::make_awaitable_signal(changeTimer, &QTimer::timeout);
            qDebug() << "awaited";
            cr.changeColor();
        }
       ....

Упр-е возвращается на точку "awaited" при выходе (или попытке выхода) из области видимости co_await (тело while). Как если бы co_await вернула какую-то футуру и по окончании итерации while сработал бы ее деструктор. И вот там задача парится до упора и выполняется переход. Др вариантов здесь не видно, больше заставлять main прыгать просто некому. Но меня смущает что это нигде не написано  

Понятно что должны быть и др средства для "ручного" упр-я, но тогда co_await должен какую-то цацку вернуть

То "first pass"

Вот я и интересуюсь "когда" - само собой это ведь не случится если main продолжил нормальное выполнение после "first pass"

Др словами если main (поток создающий задачи) не блокирован (для этого все и городилось) - то значит он может делать что угодно, и никто "извне" не заставит его сделать переход

Надеюсь это не "системный" сигнал линуха и не прерывание. А Qt сигналы и все остальное должны получить упр-е. Как оно к ним придет? Тот же фрагмент

C++ (Qt)
       while (true) {
            qDebug() << "entering loop";
            co_await qtcoro::make_awaitable_signal(changeTimer, &QTimer::timeout);
            qDebug() << "awaited";
            cr.changeColor();
        }
 

Везде утверждается (и подчеркивается) что "создатель" (main) "не блокирован". Значит после создания он получит упр-е и перейдет к следующей итерации while.  И что, он будет хрюкать задачи бесконечно? Конечно нет, наоборот, фрагмент намекает что вся возня с таймером замкнута в теле while. Тогда кто инициирует "second pass"? Таймер (когда-то) дернет? А как он получит упр-е? Ведь пока мы крутим while - событийный цикл отрезан.

Здесь неплохо описано, это тот самый случай что Вы говорите. Но это не согласуется с примером выше

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