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

Это получается вместо 1 бандла нужно будет собрать 3+ минибандлов, по одному на каждый модуль исходников. И каждый из них задеплоить, прописав в них правильно версии и зависимости. Слишком уж сложно получится. Я склоняюсь к такому - в каждом модуле, зависящем от нпм-модулей добавляется package.json с версиями. Когда формируется бандл - все зависимости сливаются и если обнаруживается конфликт версий, то кидается ошибка.

для этого есть уже готовые автоматизации по типу лерна

не скажу, что это самое лучшее решение, но в худшем случае, можно написать что-то подобное но поменьше

+ главная суть идеи в том, что у всех бандлов всегда одинаковая версия

что серьёзно упрощает жизнь потребителю пакетов

Не, lerna совсем о другом.  В MAM  другой подход к версионированию. Каждый модуль должен удовлетворять Open-Close принципу, то есть никогда не ломать API. Вместо увеличения мажорной версии - изменение имени модуля. Это позволяет одновременно работать с разными версиями API. Полезно, например, для миграций или для реализации старого API через новый. Соответственно потребителю вообще не нужно думать о  версиях.

Ноде очень не хаватает такой штуки: require( 'express@4' )

даже так

ладно, надо подумать

А можно пример, как это будет выглядеть в mol?

Например был $mol_stack, появился более продвинутый $mol_book, $mol_stack переписали через $mol_book и добавили варнинг, что вместо него лучше использовать $mol_book. https://github.com/eigenmethod/mol/tree/master/stack

Так если потребуется что-то "сломать" нужно снова придумывать новое имя компоненту 🤔

Если фантазия не работает - всегда можно добавить циферку в конце.

Но разве это лучше чем semver?

Единственный кейс, который я здесь вижу - проекту нужно две разных версии одного и того же модуля

Или я что-то упускаю?

Проекту могут быть нужны модули $ya_maps, который зависит от $mol_atom, и $goo_drive, который зависит от $mol_atom2. Типичная ситуация, когда ты зависишь от модулей разных вендоров. Даже в рамках одного вендора переход но новую версию апи может быть постепенным и растянуться на долго.

Последний кейс вполне покрывается npm с semver. У каждого модуля просто будет своя версия независимая пакета загружена.