Чем новая асинхронная модель в C++26 отличается от существующих моделей?

Мне интересно, чем они отличаются от других моделей, таких как примитивные std::future и std::promise, исполнители и ASIO Boost?

Не уверен, что вы подразумеваете под «исполнителями», если не то самое предложение, на которое вы ссылаетесь, и я не знаю о Boost ASIO, но что касается того, как P2300 (предложение, лежащее в основе той части проекта, на которую вы ссылаетесь) относится к std::future и std::promise, разница именно в том, что эти два являются строительными блоками очень низкого уровня того, что Эрик Ниблер называет «неструктурированным параллелизмом». С этими строительными блоками на вас, как на программиста, ложится большая ответственность с точки зрения управления жизненным циклом (скажем, состояний, обратных вызовов и т. д.).

P2300 является основой структурированного параллелизма, целью которого является предоставление строительных блоков, освобождающих вас от (части?) этих обязанностей. Чтобы внести ясность, Эрик Ниблер проводит аналогию между

• неструктурированное программирование (только goto для потока управления) и структурированное программирование (с for/while/if для потока управления),
• неструктурированный параллелизм (std::future, std::promise, std::mutex, ...) и структурированный параллелизм (when_all, when_any и другие абстракции, предложенные в P2300, плюс сопрограммы).

Однако это очень обширная тема, и я, честно говоря, не могу подробно ответить на вопросы (если бы я мог, я бы, вероятно, больше беспокоился о том, как я могу потратить свои 500 тысяч фунтов стерлингов в год, чем о том, как проводить время здесь). но я думаю, что вы можете найти большую часть ответа на свой вопрос в этих трех выступлениях (и по ссылкам выше):

• CppCon 2019: Эрик Ниблер, Дейзи Холлман «Объединяющая абстракция для Async в C++»
• Общая работа с асинхронностью: экскурсия по исполнителям C++ (часть 1/2) – Эрик Ниблер – CppCon 21
• Общая работа с асинхронностью: экскурсия по исполнителям C++ (часть 2/2) — Эрик Ниблер — CppCon 21

Эрик Ниблер (и в первом видео Дейзи Холлман) достаточно раскроют эту тему. Однако слишком много, чтобы дать здесь ответ. Плюс не то чтобы я понял все до мелочей :D

Эрик объяснил это в этом выступлении https://thewikihow.com/video_h-ExnuD6jms?t=525

По сути, std::experimental::future::then медленный и сломанный.

std::promise/std::future выделяет, и вам нужно выполнить подсчет ссылок для этого распределения.

Между std::promise::set_value существует состояние гонки и future::then. Чтобы избежать состояния гонки, вам нужны std::mutex и std::condition_variable.

Во время создания future/promise вы не знаете тип продолжения/вызываемого объекта. Это должен быть стертый тип, т. е. std::function, который имеет другое распределение и, возможно, косвенность через указатель на функцию. Итак, одно или два выделения, косвенный вызов функции, блокировка, подсчет ссылок. Это действительно тяжелый вес.

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