Почитал спецификацию, любопытно. Похоже на тот подход, что я сам использую в своих Backbone-based проектах для работы с формами. Несколько замечаний:

1. onSubmit не нужен, событие submit - нужно обязательно
2. useRequest - не нужен
3. Форме нужен метод getField() - получить поле по имени
4. Нужен метод getFieldsInside(el/$el) - получить все поля или поля внутри dom-элемента, если таковой передан
5. Нужна пара методов для формы addField/removeField
6. Зачем getVal/setVal? Почему не getValue, к чему эта экономия символов? Почему вообще не сделать один метод value вместо геттера и сеттера?
7. Кажется, в спецификации большая путаница со словами контрол/поле.
8. Форме не нужен setVal

По поводу контролов/полей, как сделано у меня:

1. Каждая форма содержит поля (Зачем вам модификатор form_fielded? Что за форма без полей?)
2. Каждое поле содержит от 1 до n инпута. Значение поля - массив значений инпутов. Правила валидации назначаются полям.
3. Значение инпута - это всегда строка. Инпут ничего не знает о форме или полях, может использоваться отдельно.

По поводу привязки label - нужно использовать нативный механизм, о чем тут думать вообще?

По поводу валидации, как это сделано у меня (и вам примерно так советую)):

1. Правила валидации поле получает через верстку (data-атрибут), в виде строковых идентификаторов, разделенных пробелом, например, data-rules="required email"
2. Существуют классы FieldValidator, TextInputFieldValidator, etc. Ссылки на инстансы этих классов содержатся в прототипах соответствующих классов полей.

3. У поля есть метод validate, внутри которого оно обращается к своему валидатору, примерно так:

   validate: function () {
       var value = this.value();
       return this._validationRules.some(function (validationRuleId) {
           return this._validator.check(validationRuleId, value, this);
       }, this);
   }
   

   Таким образом, валидатор получает строку - идентификатор правила валидации, массив - значение поля и само поле. Функция, которая будет вызвана для проверки, хранится в самом валидаторе.

4. Отображением невалидного состояния поля (всякие красные рамки, крестики/галочки, облачка с текстом) занимается field-status, он инициализируется на том же элементе, что и поле - для того, чтобы иметь доступ к инпутам. Его можно гибко настраивать - при наступлении каких событий менять состояние (например, показывать валидное состояние - как только поле стало валидным, невалидное - только по блюру)
5. Всплывающие облачка, описывающие ошибки (вроде "поле обязательно для заполнения") добавляются каждое один раз на страницу и доступны по тому же идентификатору, что и правило, которое к ним относится. Если нужно переопределить текст для конкретного поля - облако помещается внутрь его dom-элемента.

Хватит для одного поста, кажется.

Почему все в репозитории на русском языке?

/**
* метод зовется элементом __control
* @private
*/
_onControlChange

WTF, почему не использовать событие? Что это за приватный метод, который кем-то там зовется?

Огромное спасибо за свой опыт. ;-) Сразу вижу что поправить в спеке.

По-поводу первого списка.

1. У нас пошла пляска с неким validation отдельно от формы и полей, и этот _onSubmit, фактически, занимается отловом попыток отправить форму. В form_validate он дополнительно пытается проверить все поля согласно описанным в них правилам. Как именно будет зваться — мы пока плаваем в этом месте, но суть его такова. А нужно это для того, чтобы можно было сделать проверку на полях ввода вне форм. Антон хочет делать это тут же в блоке validation c параметром target, а я пока сомневаюсь. submit будет обязательно, даже если плохо описан ;-).
2. Резать к чертовой матери! ©
3. Есть getFields, можно сделать getField или ...ByName, но нужно понять какое API мы сможем предоставить, чтобы потом никому не сломать ничего. Спасибо, добавлю.
4. С getFieldInside — тут хочется подробностей, поскольку страшновато делать вложенные поля ввода не имея стабильной базы.
5. addField/removeField — добавлю, только тут проблемки с шаблонами на морде. Как это решать, если нет bemhtml/bh — не очень понятно. ;-( upd: может быть можно сделать зависимость по технологиями bemhtml/bh и доопределить эти методы?
6. getVal/setVal — согласен, что value лучше. Текущие — исключительно для единообразия с контролами bem-components.
7. Поле/контрол. В спеке поле — это поле формы, а контрол — это поле ввода или фактические инпуты, селекторы, чекбоксы и пр., возвращающие скаляр. Т.е. поле и контрол — это несколько про разное. Поэтому поле и может содержать несколько контролов и возвращать нечто, описанное в конце в примерах. Может быть стоит поправить терминологию, пока далеко не уплыли?..
8. setVal — Можно вырезать, конечно, но зачем работать с полями напрямую, если можно передать какой-нибудь объект UserProfile или req.body?

По поводу контролов/полей, как сделано у меня:

1. Есть мысль оставить форму максимально простой на control, которые подтягивают всякие input, attach, etc. А в _fields переписать ряд методов, типа getFields, etc. и подсунуть туда нечто похожее на control, но более тяжелое и со всякими автогенерациями полей. Получится одна гибкая и легкая форма, но все руками, и вторая типовая, и все автоматически.
2. Хочется, чтобы инпутов могло быть и 0. Тогда, например, getName → пусто, и значение не попадает в выборку, не валидируется, и вообще. «Правила валидации назначаются полям» — согласен, валидации должны быть на строки, которые из браузера приходят. Остальное можно в разных типах инпутов описать.
3. Ну да ;-)

По поводу валидации:

1. Мы пока думаем в data-bem засунуть — суть та же;
2. С этим сложнее, я бы рассказал полностью, но пост и так жирный уже ;-) Кратко: Не понятно, зачем создавать класс, чтобы проверять строку "василий" на численную регулярку, например. Я почти причесал свой proposal и скоро его залью, позвать?
3. Тут есть небольшой оверхед в случае, если нам не нужны валидаторы, и достаточно обычных полей. Впрочем, лучше отдельно про это, как и (2) ;-)
4. (да и 5) Мы это назвали message. Блочок не особо конфликтует ни с чем, поэтому не сильно трогаем. Я думал привязать его к контролу (которое контейнер для инпутов) и рулить и им, и самим инпутом из form_validate, говоря __control, что на события надо что-то сделать. Т.е. есть желание абстрагировать инпуты от валидации и сообщений через события и колбеки.

Если я чего-то перепутал — меня @verybigman поправит ;-)

p.s. По-поводу кода — в dev лежит достаточно старый код @aristov, и он не завершен. Но как база для экспериментов был ок. Кроме того, этот код уже обсуждался с bem-* core members и у них тоже были по нему какие-то планы ;-) Сами расскажут. Поэтому и в репе все на русском. дело времени.

Тут еще важно не забывать, что это всего лишь базовый функционал формы, который можно доопределять/переопределять как душе угодно на уровне проекта или бандла.

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

1 _onSubmit - нужен, без него никуда, я писал про публичный метод, принимающий функцию, как я понял, в спеке описан именно он 3 Был у меня изначально getFieldByName - за три года использования сократился до getField, не повторяйте моих ошибок) Не вижу проблем с этим методом как частью базового API 4 getFieldsInside - Я ничего не писал про вложенные друг в друга поля. Я писал про поля, находяшиеся внутри какого-то одного dom-элемента. Например, в ячейках одной строки таблицы. 6 getVal/setVal Ох уж эти яндексоиды...) 8 setVal у формы - это очень сладкий сахар, как раз он не нужен в базовом API.

По поводу контролов/полей:

1. Зря, не нужно форме про контролы знать, пусть только с полями работает. И не нужно форме с полями ничего тяжелого вместо контролов. Честно говоря, я бы просто выбросил нафиг контролы, оставил одни поля и непосредственно инпуты. Лишний слой абстракции.
2. Не понял, зачем 0 контролов. Это как вообще?

По поводу валидации:

1. Не нужно класс создавать, чтобы проверить строку на соответствие регулярке. Для этого достаточно в инстанс класса добавить правило, типа textInputFieldValidator.addRule('number', function () {})
2. Не нужно оптимизировать то, что не тормозит. Лучше, чтобы всегда все было одинаково. 4-5. Я так и написал - про валидацию знают не инпуты, а поля.

@zxqfox я думаю всех терзают смутные сомнения по поводу контролов ;)