Разные версии атомов должны быть интегрированы друг с другом. В идеале, одна должна быть реализована через другую. Иначе их нельзя будет использовать совместно. А значит это должны быть 2 разных модуля.

https://github.com/eigenmethod/mol/blob/master/form/readme.md

Ошибка?

<= Login_submit
  title <= login_submit_label @ \Submit
  event_click?val <=> event_submit?val null

Да.

Поправил, спасибо.

Появился модуль $mol_conform для реконциляции (то же, что Реакт делает для виртуального дома, но у нас на уровне данных). Характерный пример:

'return target with equal values from source and not equal from target'() {
  const source = [ [ 1 ] , [ 2 ] ]
  const target = [ [ 1 ] , [ 3 ] ]
  const result = $mol_conform( target , source )

  $mol_assert_equal( result , target )
  $mol_assert_equal( result[0] , source[0] )
  $mol_assert_equal( result[1] , target[1] )
} ,

Сравниваются по содержимому: примитивы, экземпляры (но не экземпляры наследников) Object, Array, Date, RegExp. Остальные сравниваются по ссылке, если для них не объявлен кастомный хендлер, через $mol_conform_handler. Например:

$mol_conform_handler( Date , ( target , source )=> ( target.getTime() === source.getTime() ) ? source : target )

В атомах он уже используется при записи значения, а это значит, что:
1. Запись в атом нового, но эквивалентного значения, будет игнорироваться.
2. Записываемый json-объект (или json-массив) может быть модифицирован - некоторые значения будут заменены на эквивалентные из предыдущего значения атома.
3. Несколько замедлится запись в атом комплексных json-значений, но и уменьшится число пересчётов  при их изменении. Так что общая производительность заметно пострадать не должна.

Я вот чем больше вникаю в $mol, тем больше понимаю, что:
а) зашёл не с той стороны (tree и систем пакетов здесь не основное)
б) ОРП выглядит очень круто

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

Не приходила мысль сделать реализацию в таком виде? Кажеться, что концепт мог бы быть намного чище + открылась бы возможность для довольно интересных оптимизаций

Или есть какие-то серьёзные препятствия для такого?

До создания полноценного языка я ещё не дорос, но есть в планах, да, и тоже на основе tree синтаксиса.
О каких оптимизациях идёт речь?

Я больше говорил о варианте расширения TS/JS дополнительным типом переменной и/или модификатором ппроперти по типу async. Всегда ведь можно сделать ПР в TS/babel.

Ну так декоратор и есть такой модификатор.

Как минимум зараннее можно построить полное дерево зависимостей, что позволит убрать часть проверок из рантайма + упростить методы для пробрасывания изменившегося состояния + если же дойти до реализации в самом языке это так же даст возможность лучше интегрироваться с GC

Не совсем. Мы все таки теряем возможность работы с пропертёй/ переменной в обычном стиле.

ОРП позволяет вообще от GC отказаться, так как каждая переменная знает, кто от неё зависит.

Появился компонент для рисования календариков - $mol_calendar. https://github.com/eigenmethod/mol/blob/master/calendar/

Календарики. :)

Я стоял у истоков этого компонента! :D

Дмитрий, подскажите, как корректно уничтожить созданный контрол? Я добавляю mol контролы в стороннее приложение вручную.

(function () {
 const View = $.$my_modal
 const view = View.Root(0)
 view.dom_node(document.getElementById('test_modal'))
 view.dom_tree()
 $.$mol_defer()
})()

Делаю всплывающее модальное меню, которое нужно уничтожить после закрытия.

$mol_defer.run() наверно имелось ввиду?