Стандарты синтаксиса шаблонизаторов. Первые шаги

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

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

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

Боюсь, что ваша затея обречена на провал. Слишком разные языки могут использоватся на сервере: php, perl, ruby, python, java, c#, vb.net, и сделать хорошо всем не получится никогда.

Один тег из реального проекта на Django:

<div class="plate-dishes-item {% if not dish.enabled %}plate-dishes-item_disabled{% endif %}" 
	data-order-id="{{ dish.order_id }}" 
	data-dishoptions="{{ dish.dishoption_count }}" 
	data-add-url="{% if dish.dishoption_count > 1 %}{% url buy-dish-options dish=dish.id %}{% else %}{% url buy-cart-add dishoption=dish.option_id %}{% endif %}"
	data-include-id="{{ dish.id }}"
	data-hide-on-sort="{% if dish.hide_on_sort %}1{% endif %}">

В принципе, уже не слишком читабельно, но что поделать, это очень интерактивный объект, слишком много информации о нем должно быть доступно из javascript. Но тут хотя-бы ориентация скобок подсказывает, где код шаблонизатора. А теперь давайте их уберем, заменив процентами:

<div class="plate-dishes-item % if not dish.enabled %plate-dishes-item_disabled% endif %" 
	data-order-id="% dish.order_id %" 
	data-dishoptions="% dish.dishoption_count %" 
	data-add-url="% if dish.dishoption_count > 1 %% url buy-dish-options dish=dish.id %% else %% url buy-cart-add dishoption=dish.option_id %% endif %"
	data-include-id="% dish.id %"
	data-hide-on-sort="% if dish.hide_on_sort %1% endif %">

Помоему, вообще ад.

я не понимаю может быть чего-то, но:

1. Да, здесь я согласен в общем-то.
2. Немного не понимаю о чем идет размышление если почти во всех языках есть: if ([условие]) {[тело]} else {[тело]}, зачем изобретать что-то?
3. Опять же почти во всех языках есть while, for и foreach…
   tenshi, циклы довольно часто нужны, например выводить те же комментарии или список записей в блоге
4. И снова почти во всех языках есть include [имя того что инклюдим] можно даже сделать неймспейсы.
5. Наследование… может быть я чего-то не знаю, но ниразу не видел, что бы была необходимость наследовать шаблоны.

Если в чем-то не прав — поясните, очень уж интересно.

unless — я считаю почти не нужным оператором ведь всегда можно сделать: if (!true) {}.

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

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

unless не нужен. Достаточно if, while и for i in list (опционально можно добавить for i in range(a, b) ).

Запись list.3 меня вводит в ступор, это некрасиво.

Я думаю, стоит проанализировать несколько распространенных языков и посмотреть, в каком виде там встречается вложенность объектов. В JS, например, всё единообразно, а в PHP бывают и ключи массива, и свойства/методы объектов, но тип объекта взаимоисключает эти два случая. В питоне не исключает — у объекта могут быть и свойства, и ключи массива.

п. 4 — совсем не понял, что у вас в примере написано, какое-то nameinclude. Про передачу переменных: мне нравится, как в Smarty — там при инклюде передается весь текущий контекст. Например, можно написать
{foreach from=$list item=i} {include file='file.html'} {/foreach}
и в file.html будет передана переменная $i.

Наследование — мне нравится, как в Django. Не вижу особых недостатков.