[x-yuri]

Для меня важна отказоустойчивость, расширяемость, легкость в поддержке.

компоненты будут использоваться многократно, на любой странице любого сайта и изменения может вызвать любой из них (компонентов)

расширяемость обратно-пропорциональна легкости в поддержке. Возьмем автокомплит. Какие бывают автокомплиты? Получающие данные через ajax, или через массив; показывающие все варианты со скроллом или ограниченное количество без скролла; ищущие только по началу, ищущие во всем значении. Думаю, можно еще что-нибудь придумать, но остановимся. Какое должно быть расширяемое решение?

var AutoComplete = new Class({
    initialize: function( ArraySource|AjaxSource dataSource, CompleteList|BriefList list ){...}
    ...
});

var ArraySource = new Class({
    initialize: function( StartingWithStrategy|SearchAnywhereStrategy searchStrategy ){...}
    ...
});

var AjaxSource = new Class({
    initialize: function( StartingWithStrategy|SearchAnywhereStrategy searchStrategy ){...}
    ...
});

Итого, семь классов. Что мы получили? Правильно, Hello, world! in patterns. И оно так же не легко в поддержке, как и в использовании. Да можно сделать это не таким расширяемым и оно станет проще. Но это не MVC и я не вижу причин разбивать этот автокомплит на модель-вид-контроллер. А вы?

Именно не "удобное API", а интерфейс взаимодействия. Что посоветуешь?

т.е. не библиотеку, а фреймворк. Посоветую не ограничивать пользователя (MVC/неMVC, события/несобытия). Просто предоставь пользователю удобные средства для реализации разных способов взаимодействия, реализации модулей

Модули же эти должны реализовывать логику. Представление данных, отдаваемые ими, может быть совершенно разным (один модуль на 10 сайтах).
Сам модуль будет состоять из описания логики, представления и данных.

ты себе противоречишь, или шаблон будет преобразовываться в конкретную разметку на каждом конкретном сайте? А что с css/js. Ведь они с DOM работать будут, т.е. должны зависеть от этой конкретной разметки. Или тоже будут преобразовываться/работать через промежуточный слой?

кроме того, ты уверен, что у тебя MVC, а не HtmlCssJs? Ведь можно сказать, для того же select, что модель там - пункты списка и какой из них текущий, вид - html+css, контроллер - js

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

звучит как маркетинговый ход:
- Посмотрите, как просто в нашей программе сделать вот ЭТО!
- Вау, прикольно, а как насчет вот такого?
- А... Э... Ну, я вам потом расскажу... если захотите
(ну это так, подумалось)

da_ff (и не только), не обязательно подробно рассказывать реализацию. Просто пример привести. Например, связанные списки. Они не могут просто реагировать на изменение любого другого списка, потому что я добавлю третий список и обновляющийся список будет реагировать на события от двух списков. Т.е. должен быть какой-то код, специфичный для формы, который связывает списки. Надо сделать так?

<pr:list id="list1"></pr:list>
<pr:list link-with="list1"></pr:list>

И чем это отличается от

var list1 = new List();
new List({'link-with': list1});

просто другая форма записи
Хотите Mediator? Пожалуйста, надо только дважды расширить list, придумать для них какое-то свое событие, один его будет отправлять, а второй слушать

<pr:list-1></pr:list>
<pr:list-linked-with-list-1></pr:list>

ваши варианты?

Panzermaus, интересно, т.е. у тебя полный MVC один большой MVC? Т.е. много моделей, много видов и один контроллер и нету соответствия между видами и моделями? Ну да, раз должно быть undo/redo, должен быть какой-то координатор. Да и взаимодействие там, наверное, сложное, так что наличие координатора вдвойне имеет смысл. Но я говорил про нечто не такое высокоуровневое. Т.е. у тебя виды как реализованы? Один класс? Или разбиты по принципы input/output, один класс изменяет DOM, второй реагирует на события? Или как удобно в каждом конкретном случае?
И еще, я правильно понял, что виды не принимают уведомления напрямую от модели и контроллер не уведомляет виды о каждом отдельном изменении, потому что некоторое действие вызывает цепь изменений, а контроллер дожидается пока это все завершится и сообщает видам, что изменилось пакетом, а не про каждое изменение по отдельности?