After some thought, I believe that the main problem with the proposal – and the cause of some reservations expressed in this thread (especially by @pf_moore and @MegaIng, if I properly understood the crux of your messages) – is that the term template promises some kind of skeleton or form, or a structure – which can be filled later with actual content.
In other words, I bet that many people, when hear about template strings, will expect that their usage, once a template string will be evaluated resulting in a template object, will then include the possibility to fill that structure (template) with some content, e.g.:
template = t"Monty {animal} and the Holy {cup}"
filled = template.fill({"animal": "Python", "cup": "Grail"})
# and maybe only then:
html(filled) # etc.
Whereas the proposed syntax, with the associated types, offers just a way to immediately define structure and content, which then (typically) is only meant to be completed with certain presentation qualities (such as DSL-specific escaping etc.).
What I am trying to express is that IMHO the feature is interesting and probably very useful, yet using the term template to describe it would lead to misunderstanding and disappointments – at least unless it includes some actual templating possibilities, i.e., some natural way to decouple defining structure from defining content.
PS [EDIT] Let me clarify: the above code snippet is not something I propose, but something I am afraid people will expect when they hear about template strings.
PPS [late EDIT] But, said all that, I’d like to emphasize that the proposal described in the point (3) of my later post (and in further posts following that one) could help greatly reduce the above issue.