I'd call it rather the strongly typed equivalent of Spolsky's Hungarian notation solution.

Maybe; it's pretty easy to violate the typing discipline and destroy the safety properties one might hope it would provide. You just define a class (or, in the Haskell version, a language) whose flatten method returns something unsafe --- or maybe even instantiate an existing class or language with an unsafe string.

There's also the occasional time when you'll want multiple encodings applied, such as when substituting into a javascript variable that you then insert into the innerHTML attribute of something else on the page.

There's very little excuse for that; certainly the case you're citing would have been better off with document.createTextNode, which happens automatically if you use MochiKit.DOM, which is a sort of JavaScript port of Stan.

So even with this kind of approach, you're still going to want to annotate spots in the template to describe something about where the field is being used...

Yes, you are right. I mean, you could put that into the values to be substituted as well, but that's clearly the Wrong Thing. That's what I did the last time I implemented this approach, though. (I find that I haven't yet posted that code to kragen-hacks, so I'll send it out this week.)