Да, в общем-то никаких.

Но например в контексте перла это означает, что subroutine signatures в прод никогда не попадут. А значит программерам на поддержке-развитии такого проекта не интересно заниматься современными версиями перла (хотя бы даже проверить их на регрессии). К примеру я до сих пор не дошёл до проверки новых try catch, т.к. мне и на Try::Tiny хорошо.

Если бы поддержка новых синтаксисов бэкпортировалась (а технически в перле для этого всё есть), то ситуация могла бы стать лучше.

Ну если ты хочешь новых штук, будь любезен избавляться от старых.

Это значит что кто-то зажал бабла на нормальное тестирование и нормальную организацию разработки. Если эти сценарии нужны - они должны быть покрыты тестами, если не нужны - удалены нахуй.

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

Это не по этой схеме, это из-за того, что такие вот фанаты обратной совместимости не дали ввести JIT, упрощение синтаксиса и прочие радости жизни.

Речь то не в том, что бы избавиться. А в том, что апнуть версию нереально сложно. Ладно бы апание занимало несколько дней.

В JS тоже фанаты совместимости, но там JIT взлетел (кстати, как раз ценой временного отказа от новых фич, типа let, но при этом была транспиляция).

там в JIT взлетел потому что пришел гугл, положил болт на фанатов совместимости и сделал то, что ему надо.

ну кажется тут все зависит от стиля разработки. Если ты любишь хитрожопые TIMTOWDY и эксперементальные штуки в проде - дорогой майнтен и миграция твоя плата. Если ты пишешь скучный код с использованием стабильной части языка - не уверен что там "нереально сложно".

И когда в следующий раз гуглу что-то сильно понадобится - фанаты совместимости будут посланы в хуй и будет сделано как надо

Что в их JIT работает не так, как в соответствующей версии JS? Наоборот, они сделали так, что программисты вообще ничего не заметили.

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

Так вот, увы, в Perl - нет... Там это ещё усугубляется тем, что переход на новые версии обычно требует новые версии библиотек, а они притягиваю более новые версии зависимостей, а там где-то меняется например поддержка юникода - и всё, приплыли.

Мешает, т.к. спецификация (если её выписать из существующих нюансов реализации) Perl на порядок больше.

это только вопрос необходимых трудозатрат, а не принципиальной невозможности реализации. Плюс ничего не мешает сделать это в перл 7 со сломом совместимости.

Сломать совместимость никто не мешает, только как Perl 6 никто не использует, так и Perl 7 не будет. Собственно, разговор как раз об этом - совместимость важна. :(

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

Это только теория. Существующие случаи это не подтверждают. На практике - не "все", и не "прекрасно".

Точнее, вопрос в скорости изменений. Если "до основанья, а затем", то практически никто не перейдёт - как в случае с Perl 6.
А если иметь план, и на каждом этапе менять только абсолютно необходимое, то есть шанс, что кому-то будет легко переходить между минорными версиями, а раз адепты будут пользоваться свежими версиями, это повышает шанс того, что оставшиеся проды будут переписываться на мажорные версии "кумулятивно".

Типичный пример - когда добавляли given/when в 5.10. Добавили - молодцы? Но нафига было при этом ещё "на всякий случай" захватывать лексикализацию $_?

А причем тут перл 6? У него же вообще преимуществ вроде нет. Ну кроме "смотрите как красиво написано и символ атома для атомарных операций"

Асинзронщина там охуенно сделана