[B~Vladi]

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

Они разделены, смотри пример выше.

И еще какие-то свои у тебя там исключения, эти я не знаю куда.

Я не знаю уже как объяснять. Мы, походу, о разных вещах говорим.
Вызвал функцию с аргументом - числом. Функция ожидала строку. Либо функция сама падает (например, пытается применить к аргументу метод строки), либо она проверяет тип и выкидывает исключение. Т.е. это то же самое, что и ошибка программиста, о которой ты писал выше.

Что касается ошибок обращения к ресурсам. Сами обращения происходят в недрах логики метода, вызываемого из шаблона, правильно? В ноде принято в callback первым параметром прокидывать объект ошибки, если это имеет место быть. Так вот, допустим в недрах этого метода возникла ошибка обращения к ресурсу и логика метода это отловила. Метод может передать в callback этот объект и уже в шаблоне на уровне разметки это обработается. Пример:

<ten:query method="getOnline" params="error, data">
  <ten:if expr="error">
    <!-- произошла ошибка доступа к ресурсам или ещё что -->
  <ten:else if="data" />
    <!-- всё ок, пришли данные, обрабатываем их -->
  </ten:if>
</ten:query>

Если ты про это говорил, то всё разделено. Если нет - расскажи на примере что ты имел ввиду.

f(1, 2, 3)

Это у меня записывается не так, не стоит надумывать
Тем более, в том же Dust можно вызывать функции и обрабатывать от них результат. Логика таких конструкций ничем не отличается от моего шаблонизатора (см. пример с query, context), кроме синтаксиса самих конструкций.

Которые на самом деле код, императивный код.

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

Для этого надо дергание ручки вынести из шаблона, а в шаблоне принять результирующие данные.

А мне не нравится такой подход. Мне страшно представлять огромное дерево данных. Особенно, когда они максимально соответствуют структуре представления. Пока никаких веских аргументов я не увидел (или плохо смотрел?), кроме религиозных убеждений. Из всего нашего диалога мне больше всего интересно узнать по-че-му надо так а не так? Я правда хочу знать, открой мне глаза

А записывание кода разметкой ничего не меняет, кроме понижения читабельности:

Ох. Ну где я записываю код разметкой? Вызовы методов? If-ы? Циклы? Кстати циклы (итераторы, ага), ифы, вызовы функций есть в каждом приличном шаблонизаторе. Чем мой от них отличается?
А, я понял. Тебе нравятся шаблоны типа:

<% for (var i; i < array.length; i++) { %>
<% } >

А не нравится тем, что это для меня не актуально

Хм. Поэтому не нравится? Т.е. если мне это не надо - то говно. Так получается?

ну так я и предлагаю разделить активную и пассивную составляющие по разным файлам.

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

Декларативные шаблоны легче понимать, чем императивные.

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