а если и упадёт - не жалко

Если бы я делал язык программирования с нуля, каким бы он был? Пофантазирую вслух. 1. Его компилятор (транслятор/интерпретатор) был бы очень рано забутстраплен с его же стандартной библиотеки. Пользу eating your own dog's food невозможно переоценить. 2. Я бы исключил из него математику (всю). Даже a = a+1 нельзя было бы написать. Вообще её наличие в языке уходит корнями в Fortran и другие мастодонты, а у нас немного другие нужды. Есть итераторы, есть ranges, хотите математики - велкам в библиотеки, не устраивайте мне тут mathcad. Заодно и массивы выкинул бы. 3. Уровни доступа переоценены. Достаточно было бы всего 2 -- public и package-protected (доступен только в этом пакете). Сделать public поля нельзя. 4. Пакеты. Само собой. Вложенные пакеты запретить. Вложенные классы - в пакет, в класс, в метод - разрешить. 5. Сделать метод или класс закрытым от наследования нельзя 6. Никаких setter-ов и getter-ов - только функции/методы. Ссылки на объекты и другие сущности должны быть first-class citizens, а не стыдливо вести себя как бесплотные указатели, унаследованые из си. 7. Модули - как класс, но существует в едином экземпляре, как пакет. 8. Типобезопасные макросы в языке иметь хорошо и правильно, но не на уровне syntax tree, а выше. Хотя можно не прятать это в компилятор, а выпустить macros sdk 9. JIT и эффективный GC переоценнены, а вот repl и хороший анализ ошибок - их, наоборот, не хватает 10. Все доступные инструменты сборки чудовищно гибкие. Модель требует переосмысления, и начинать его надо со сбора требований, при этом важно избежать ловушки, когда нам кажется, что требования и так выявлены (что там непонятного, это же очевидный сборщик). Мне кажется, уже на этом можно не одну голову сломать, но труд этот будет вознагражден.

Почему зафейлилось-то? Развитие-то продолжается

Я не хочу срачи устраивать. Просто я глубоко сомневаюсь, что можно эти ваши асинхронные исключения подогнать под чистую лямбду. В статье выше в качестве семантики используют трансляцию в pi-calculus. Белый гуглинг не дал мне ни трансляции, сохраняющей операционной семантику, пи-исчисления в лямбду, ни лямбда-обоснования для асинхронных исключений.

Я очень плохо в курсе, но вообще не припомню, чтобы в подходах с грязными лямбдами межпотоковый обмен эксепшнами как-то лучше решался. Во всяких ерлангоакковских актор моделях проблема по сути игнорируется. Но если посмотреть мотивацию в той статье - то само желание потока убить своё дитя рождается, как правило, от осознания, что он ему больше не нужен. А нежелание умирать, как сказал Александр, от осознания, что есть неосвобождённые ресурсы. Поэтому чисто из интуиции из соседнего чата проблема как-то должна решаться линейными типами или типа того, которые вполне вяжутся с чистыми лямбдами. Т.е. если широко посмотреть - ручное управление асинхронностью так же плохо вяжется с чистотой, как и ручное управление памятью.

Вообще я тут поразмышлял: на самом деле можно попробовать реализовать асинхронные эксепшоны и маск/анмаск с помощью хитрой стратегии редукции. Попробую подумать ещё и формализовать

https://github.com/lexi-lambda/hackett вбрасывали уже?

зачем нужны монады в энергичных динамических языках?

для чистоты