ココに書いた事情で、Kuwataさんにいろいろと作業していただいています。StringTemplateは、僕が気に入ったテンプレート言語／エンジンですが、Kuwataさん曰く：
[注：StringTemplateの]致命的な弱点としてはデフォルトで HTML 特殊文字がエスケープされないことが発覚。これは StringTemplate があくまでも汎用的なテンプレートエンジンで、特に Web ページの出力に特化しているわけじゃないのが原因だろう。
StringTemplateは確かに汎用エンジンで、メールの定型文を生成するのにも使えます。特に、パーザージェネレータANTLRと組み合わせてソースコードの生成に使う用途を強く意識しているようです。よって、HTML特有の処理が組み込まれてないのは、まーしょうがないでしょう。
さて、HTMLエスケープの問題（例えば、"<" を "<" に直す）は、ベンジャミン・ヘール（Benjamin Geer）という人に指摘されたらしく、"Enforcing Strict Model-View Separation in Template Engines"（http://www.cs.usfca.edu/~parrt/papers/mvc.templates.pdf）の "8.1 Attribute Rendering" で扱っています。テレンス・パーはJavaを例に説明してますが、以下ではプログラミング言語に依存しないで、テレンス・パーのアイディアを述べてみます。
テレンス・パーは、テンプレートを展開するときの環境を「属性セット」とか「属性テーブル」とか呼んでいます。属性値には、整数とか文字列とかのデータ型があるのですが、テンプレート展開の時点ではいかなるデータも文字列にする必要があります。例えば、整数 23 は文字列 "23" としてテンプレートのプレースホルダを埋めることになります。
このようにプログラムから提供されたデータ（属性）を文字列化する変換を（誤解を招きかねない用語ですが）レンダリングといい、レンダリングを担当するナニカ（関数とかメソッドとか）をレンダラーと呼びます。文字'<' をそのまま出力するか、"&" に直すか、あるいはその他の表現に置き換えるかなどは、レンダラーが知っている、とするのです。
当然に、レンダラーは出力フォーマットに依存するし、出力フォーマットごとにレンダラを切り替える必要があります。HTMLフォーマットに対してはHTMLレンダラーを使い、プレーンテキスト・フォーマットに対してはプレーンテキスト・レンダラーを使う、という具合に。
この方式をテレンス・パーは MVCR (Model-View-Controller-Renderer) と呼んでいます。レンダラーが、属性（プログラムからのデータ）とテンプレートとの橋渡しをするのです。この方法によってエスケープの問題は解決すると彼は言いたいようです。
が、ほんとうでしょうか？ ある文字列をHTMLファイル内に挿入するとして、div要素内とpre要素内とscript要素内では、エスケープ方法や改行の扱いが微妙に違ったりします。とはいっても、HTMLファイルを真面目にパーズして判断するのは非現実的です。
また、PHP Smartyで言うところの修飾子（Django Template で言うところのフィルター）を考えると、レンダラーと修飾子の実行順序が問題になったりして、なかなか一筋縄ではいきません。思いのほか根が深い問題のようです。さーて、どうしたもんかなー。
