Ну Андрей говорил про конкретно тайп-класс ориентированные штуки. Тут я соглашусь. Хотя в котлин это, судя по всему, тоже будет добавлено в не столь отдаленном будущем.

Ну там очень многое из коробки есть ) тот же codable например, но это все легко добирается либами от JB

И в более удобном виде, так как кодабл не предполагает возможности разные реализации сериализации для типа определить, в отличие от. Разве что с костылём в виде делегированных пропертей, которые тоже не самые приятные в использовании.

Но мы о добавлении языковых фич в котлин, а не о том, что можно либами накрутить)

а паттерн-матчинг будет? :)

с деструктуризацией

Вчера обсуждали же. TL; DR - вероятно, но не быстро ибо сложна.

Знает он о котлине

Понимаю что офтоп, но блин..
весь это зоопарк в моих глазах оправдается только тогда, когда рядом будут объяснения, почему сделано так, а не иначе

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

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

Синтаксис не первичен. И парадигма не первична. Первично использование.

Это инженерная штука. Чтобы понять, почему так, надо уже иметь пару лет опыта.

Это об опыте в конкретной экосистеме? или другое имели в виду

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

К примеру, в луа наверняка возможно было сделать лямбды с фигурными скобками, но во всём остальном языке операторные скобки в виде ключевых слов, потому по б) фигурные скобки не катят.

В С++11 однозначный способ неявно захватить значения невозможен, потому пришлось квалифицировать его дополнительно. Пришлись кстати квадратные скобки перед круглыми, которые по а) никак иначе парсер понять не мог.

Ну и т.п.

Ну значит считает скалу единственным подходящим для подобного стиля языком на JVM. Да и ладно.
(А что там, Eta окончательно окочурилась?)

Наверное надо выкинуть из рассмотрения все языки, которые вынуждены были втискивать лямбды в изначально чуждый синтаксис, сильно постфактум
А вот для остальных интересен маппинг цели -> решение

синтаксические трудности?

И они тоже

Даже если выкинуть их и оставить те, где лямбды с первой версии. У вас зоопарк синтаксических конструкций для лямбд вызывает вопросы, а для всего остального нет? Или почему вы тогда конкретно их подсветили?