1) Пейтон Джонс - это руководитель и основной автор GHC вот уже лет двадцать как.
2) Первая же ссылка с этой страницы (compiling without continuations) ведёт на его (с соавторами) статью, в которой эти самые join points определяются.
3) Вводится фича в компиляторный IR, который, как я уже сказал, ориентирован на ленивые языки (т.е. хаскель) и 1-в-1 не применим к JVM/Java/Scala.

Но в самом деле, если внимательно отнестись к докладу Курпатова, и сопоставить это с теорией Bullshit Jobs Дэвида Грейбера. Посмотреть с какими проблемами сталкиваются разработчики ИИ. И правда задуматься о том, что многие вещи мы перестаём контролировать... ну например чего стоят ботнеты на wi-fi точках. Ещё несколько лет назад такое и представить было сложно.
В целом то есть о чем задуматься. И это все тревожно очень.
А то что падает уровень интеллекта, так об этом не только Курпатов говорит. В Норвегии, например, обратили на это внимание, на основании тестов призывников в армию.

4) Паттерн матчинг в хаскеле по семантике исполнения - это совсем не то, что в Scala/C#/Kotlin, и опять же в основном из-за ленивости. В хаскеле это единственное место(!), где делаются не-ленивые вычисления, и вся компиляторная и рантаймовая технология для него заточена на это.

SPJ очень давно не основной контрибьютор GHC, тема с джойн пойнтами выросла из секвенций, основные авторы всей серии статей(захватывающей) Downen и Ariola, имлементером был Люк Маурер

2) ага
3) Идея не про весь IR, а про добвление в имеющийся IR на базе System-FC двух новых конструкторов.
В граальный жавовый AST это тоже вполне затаскиваемо.

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

Ну, да, так и будет. Обратная совместимость заставит спецификацию фич быть сложной (как уже доказал доклад), сложная спецификация приведёт к сложной имплементации, что может привести и к неочевидностью и к багам. Что-то поправят.

Но избегание фич это не совсем подход мейнстрима. Что-то похожее сделал Го, конечно. Уменьшили количество фич, уменьшив порог входа почти до нуля. Какой-то эффект это даёт. Но если у тебя уже ненулевой порог входа, зачем тебе давать фору тем, кто не боится взять себе фичи?

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

Джава - не ООП язык уже, а мультипарадигменный. Кому-то класс это для ООП, а кому - значения поскладывать вместе, этакие именнованые туплы или произведение типов. Наверное было бы неплохо, чтобы те, кто пишет классы без логики, могли жить лучше. Да и опять-таки, не та фича, которую тебя заставляют юзать.

4) ленивые паттерны тоже есть, но суть совсем не в них. В исходных работах рассматривался строгий язык в т.ч. Никаких "особенностей", которые принципиально мешали бы воткнуть джойн пойнты в текущую компиляцию Graal мне лично не видно

Еще раз, речь не о фиче, речь о пользе VS рисках от её корявого внедрения в чуждую среду. Со стримами и лямбдами польза все же перевешивает риски. С пмом - увидим, но мне как то скептично.

5) Конструкторы в хаскеле - совсем не то, что в скале. Хасклевский "объект" - это closure без identity, без runtime -полиморфизма, без type tests & type info, без mutable state. А то время, как в скале - это настоящий ООП объект. А на JVM - java.lang.Object. Со всеми вытекающими.

нет

Поэтому, во-первых, эти дуальные определения для Scala/JVM не очень применимы, а во-вторых, они не очень и нужны - всё, что нужно - это скаляризовать объект (убирать боксинг), а для этого не нужно вводить какие-то дополнительные конструкции в IR или JVM. Или я чего-то не понимаю?

А уровень интеллекта падает или тесты устарели? Как это достоверно определить?

Все же в какой бы парадигме ни сидели, не получится игнорить тот факт что класс это нечто большее чем структура. + эта история с recordами. А значит где то придётся колхозить. Изобретать деконстракторы? И ради чего? Чтобы лямбды вместо трех строчек укладывались в одну? Ну ок, но интерес так себе.

Ну, тут два "простых" решения:
1) Писать на котлине. Про instanceof согласен, это довольно тяжелое наследие.
2) Пытаться повлиять на процесс согласования фичи. Да, типы местами избыточные (не всегда, как мне показалось), надеюсь, что какого-нибудь слова var перед всей конструкцией хватит. Не просто же так его добавили :)

Не могу ответить на этот вопрос. Тут либо становиться экспертом в данной области, либо верить нескольким независимым источникам.
Нептун я тоже не видел. Но вроде как он есть.

Ну, в текущем дизайне пока получается. Там, где очевидно (рекорды), всё без боли. Если неочевидно, то сам решай, где ты хочешь писать код: в момент описания класса или в момент использования объектов класса.

Это вообще непонятно

А где эти независимые источники? Помоему господин Курпатов заинтересованное лицо.

Тогда остаётся наблюдать и выбирать из того, что есть (языки)
Конкретно в этом кейсе (то, что с instanceof это не прямо очень лаконично) - ну да, в теории можно лучше. Но это всё ещё выглядит приятнее, чем при отсутствии этих фич.