DmSerkealon(Ruslan)как либу + какой-то базовый RTL к ней напишешь так и будет
не вижу никаких причин вводить для этого синтаксический сахар, текущих языковых возможностей с лихвой хватает

В целом мне хватает Indy. С нею стиль программирование такой же удобный, как в C# / JavaScript при использовании async/await. Разница только в том, что в Indy на каждое подключение выделяется отдельный поток, а при async/await потоки выделяются при необходимости, один поток может обслуживать десятки подключений.
В другой стороны, потоки в Delphi намного легче, чем потоки в C# / JavaScript. В Delphi при создании потока выделяется порядка 16КБ ОЗУ (+ ещё 16КБ, если Windows 64-битный, а прога 32-битная). Таким образом, установить несколько тысяч потоков (если и прога и ОС - 64-битные) - не проблема. Важно с таким количеством потоков избегать использование Sleep (особенно Sleep(0)), иначе планировщик задач Windows загнётся.
Не знаю, сколько подключений можно установить на C# с его async/await. Скорее всего больше, чем в Indy (а может и меньше, тупо может начать тормозить основной поток, из которого на практике вероятнее всего начинаются await-вызовы из-за того, что будет быстро заполняться очередь сообщений у потока).
В этом плане лучше всего GoLang - у него нет потока, у которого может заполнится очередь сообщений и он начнёт тормозить при её обработке, поэтому без проблем может держать десятки тысяч подключений, причем ему для этого хватит лишь несколько десятков потоков Worker. Правда, у него есть поток диспетчеризации, который раскидывает задачи (горутины) между тредами и копирует куски стека, в него всё может упереться. Вроде такую же вещь сделали и в котлине - скрестили оба подхода - там и аналог async/await и копирование кусков стека корутин.мда...
вас послушать, так шарписты и голубцы под какими то разными ОС запускают свои программы
я вот прям перекрестился, до пенсии мне работы хватит

DmSer,

Физическая память без нужды, да, не выделяется, на старте потока 1 страница всего
Но, что бы была возможность увеличить его до max stack size нужно зарезирвировать для этого адреса на весь этот объём - а они очень быстро конечны.

По поводу, повторить то, что сделано в .Net - совсем не Rocket Science.
Если упрощённо, то там просто пул потоков разгребает нити с задачами из IOPort

Сам диспетчер написать, это строчек 500
А вот с библиотеками которые будут его поддерживать уже проблема
Даже минимум вроде работы с примитивами блокировки, файлами и сетью при переписке на overlapped-режим потянет на несколько человеко-месяцев разработки.
Если замахнуться на гуи, то объём вообще становится непосильный