1. Неоднократно думал о необходимости дополнительного модуля, типа CCK (Content construction kit). Суть в том, чтобы в удобном интерфейсе определять какие поля нужны для того или иного типа страниц, какие из них отображать при создании, какие при редактировании. А в шаблоны просто вставлять обобщенные тэги {CCK_PAGE_ADD} / {CCK_PAGE_EDIT} (или вообще единый). Тогда вопрос нужной/ненужной унификации решается сам собой, кому нужно тот пользует, кому нет - сидит на старых шаблонах. Но вот на пути реализации есть одна загвоздка - см. пунтк 2.

2. На самом деле об этой проблеме я уже писал (#1152). Можете там прочитать - там подробно. Если кратко то проблема в том, что мы не имеем единого стандарта именования переменных языкового файла, которые отвечают за названия «стандартных» полей форм. Это хорошо видно на примере модуля «pages» (см. описание на ГитХабе). 

• удобство - да, оно появляется
• гибксть - да, она сохраняется, т.к. относительно исключения page.add.tpl, сли он нужен, речь тут не идёт
• несиметричность - да, возможна, не юзайте обобщённый шаблон

Примитивные сайтики станут на один шаблон короче

И не примитивные тоже станут на один шаблон короче.

у эдит есть: OWNER DATE DELETE и другие, которых нет у простого add / да и зачем крушить шаблоны

это легко обходится условиями

редактирование данных шаблоно в занимает 2 минуты

на небольшом сайте да.

Конечно, старые сайты, возможно, и придётся обгрейдить, но это же не причина отказываться от нововведения.

Многие голосуют не осознвая подводных камней.

На этапе разработки сейчас мне достаточно дефолтного page.add из папки с модулем. Вся работа идет только с page.edit. В конце они унифицируются по п. 1. Никаких лишних проблем и телодвижений это не требует.

Часто и в add и в edit используются конструкции IF / ELSE с проверкой разделов, в нескольких проектах у меня, например, использованы селекты и jQuery. Часто add и edit шаблоны вообще не симметричны (запрещена смена раздела или ключевого экстраполя).

Дефолтный page.add из папки модуля теперь не будет подтягиваться? Или его не будет? Или как?

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

Примитивные сайтики станут на один шаблон короче. Там, где необходима гибкость, ничего не улучшится (да и зачем?)

Нет.

Добавлено 1 минуты спустя:

редактирование данных шаблоно в занимает 2 минуты... а вот header и footer надо объединить имхо

в общем вечер думал - шаблоны все-таки не одинаковые. я против.

Про это и речь - шаблоны будут объединены, но различные шаблоны в несколько файлов по-прежнему можно будет использовать, так же лучше, имхо.

-дожна остаться возможность различных шаблонов, например на сайтах, где разные права у юзера и админа - там и шаблоны очень разные нужны.

- это начало переименовывания тегов. А если переименовываем в 1 месте, то летит гора плагинов, и это меприятие требует замены кругом шаблонов

Добавлено 4 часа спустя:

в общем вечер думал - шаблоны все-таки не одинаковые. я против.

За, но полностью исключать page.add.tpl думаю не стоит - если он есть в скине, использовать его.

В целом тоже «за». Однако согласен с «Moool»,  и изложил несколько вопросов и предлождений в английском топике.

Мы получили удобный инструмент для управления страницами.

В формах страниц параметры полей стали одинаковыми при редактировании и создании страницы, нарпимер названия полей: rpage<имя_поля>

Предлагаю отказаться от разделения шаблонов для создания и редактирования страницы и объеданить все в один шаблон. Это разделение тянется с давных времен и ничего кроме дублирования html-кода не несет. Особенно полезно для сайтов, где еще и для разных категорий множество разных шаблонов редактирования страниц, зависящих от наборов экстраполей полей.

Для себя я этот вопрос решаю планигом т.к. сейчас реальная разница в этих шаблонах только в префиксах тегов. Но может пришла пора от этого избавляться?

А, если у кого-то есть специфика требующая вывода одних полей при редактировании страницы и не вывода их при добавлении, то это легко решается условиями.