1) Интерпретируемый язык. В компилируемом желаемое вряд ли реализовать.
2) Персистентность. Это значит, что закрытие программы лишь приостанавливают ее работу и она начинается с того же момента при повторном запуске.
3) Легкость отката, управления версиями. Как самой конфигурации программы, так и файлов-продуктов её работы. Под конфигурацией понимается максимальнейшим образом полное ее текущее состояние, о котором говорится в пункте 2.
4) Атомизация всех процессов (не уверен насчёт термина). Если какое-то действие возвращает ошибку, вся конфигурация автоматически откатывается до момента исполнения этого действия.
К примеру, есть кнопка "ABCDEF", она запускает 10 последовательных инструкций. 5 инструкций выполняется нормально, 6-я возвращает исключение. Состояние возвращено на момент окончания 5-й инструкции, независимо от того, насколько сложный и объемный код должна была выполнить или успела выполнить 6-я инструкция. Пользователю предлагаются варианты: на месте исправить код 6-й инструкции и немедленно возобновить работу (например, виной ошибки какая-нибудь мелкая опечатка), либо передать исключение на уровень выше. Если пользователь выбирает второе, конфигурация откатывается на момент ДО нажатия кнопки "запуск". Глубина погружения, разумеется, не должна быть ограничена двумя уровнями. Т.е. если 6-я инструкция запускает код из 100 инструкций, в котором 47-я инструкция ошибочна, можно будет либо исправить 47-ю, либо передать исключение на уровень выше и исправить вышеописанную 6-ю.
То бишь на самом поверхностном уровне, нажатие кнопки — всегда атомарное действие, которое либо выполнено полностью, либо не выполнено с ошибкой, и это никак не отразилось ни на чём.
5) Простота дробления конфигурации, копирования внутренних объектов, сохранение их прототипов.
6) Гибкость непосредственно языка.

Нет.

2) и 3) реализуемо только на уровне ОС. Существуют проекты в этом направлении, но они еще далеки от завершения.
4) такого не встречал
5) не понятно что вы имели ввиду.

Лисп же. Правда, их много разных.
1) да
2) штатная фича. Можно образ работающей программы сохранить и развернуть потом.
3) это тебе придётся делать самому. Впрочем, программирование в функциональном стиле (когда функции имеют вход, выход и не имеют состояния и побочных эффектов) сделает это проще.
4) там есть всякие страшные слова типа REPL (некая смесь дебаггера и командной строки) и continuations (способ восстановления после ошибки).
5) в лиспе принято свободно оперировать как кодом, так и данными.
6) классный язык, с 70х годов активно используется.

Вообще говоря, нужно сохранять состояние не всей программы, а только внутренней части, самой скриптовой машины. Если посмотреть на какой-нибудь Excel, документ можно сохранить и загрузить в любой момент, можно отменять последние действия. Хотя возможность отмены теряется при перезапуске.

Лисп сложен, но при этом механизм отката и персистентности придется неизвестно как делать самому. В плане гибкости поглядываю в сторону луа.

Что бы штатной фичей было — это где такое?

Персистентность самой программы в лиспе встроена. Самому придётся мудрить персистентность внешних файлов.

Транзакции.

Я джва года ждал такой(с) язык.

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

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

А вот желаемый откат файлов-продуктов на уровне языка программирования вообще ставит меня в тупик.

А меня нет. А, в таком виде, конечно.

Вот и я первым делом представил откат форматирования диска. То есть, как раз не смог представить.

Каждой программе - по виртмашине-песочнице, чо.

unformat же