OberonCore

Что это с практической точки зрения означает? Довольно большие проекты на node.js как-то собираются, несмотря на эту проблему (смысл в более чем полиномиальной сложности)? Без этой фичи как-то грустно. С т.з. надёжности лучше указывать одну конкретную версию, а с т.з. удобства диапазоны имеют смысл.

Означает, что при большом количестве компонент поиск подходящих версий будет долгим. Означает, что сам алгоритм поиска сложный, и протестировать его сложно.
Хотя, о чём это я? Алгоритм-то не на JS делаться будет, а на Обероне. Значит с реализацией и скоростью проблем не будет

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

У Хельмута сейчас нет этой системы версионности поскольку он вручную проверяет пакеты. Если что-то несовместимо, то общается с авторами пакетов. Я так представляю себе как там у него процесс устроен. В целом хочу отметить, что интерфейсы расширений расширяются постепенно и совместимость ломается крайне редко. Больше зависимость от версии Блэкбокса. Ну и тут уже разработчик выбирает под свой проект. Так что такой системы как в npm не вижу смысла пока внедрять.

Ну, тебе виднее. На данный момент я понял, что мне предстоит составить свой список компонентов, чтобы сориентироваться в мире BBCB Поскольку просто список компонентов - это не то же, что пакетный менеджер, и составить его гораздо проще - достаточно найти все сборники и составить их перечень, а потом прочитать. А до пакетного менеджера как-нибудь потом (может быть) доберёмся.

Спасибо Дмитрию Викторовичу за публикацию своего расширения Scl.
https://blackbox.obertone.ru/component/Scl

Добавил строки Ивана Горячева и списки от Петра и Ивана Кузьмицкого.
https://blackbox.obertone.ru/extension/Strings
https://blackbox.obertone.ru/extension/Lists