Considering that razor is not html/mvc specific I'm not sure this is a good idea. Rather than the base implementation implement IHtmlString it should be a custom implementation that does it. This allows for usages outside of areas that require encoding.

HTML will be the most common use-case though. The IHtmlString interface doesn't tie it to HTML, but provides a built-in code path for specifying how the string value should be handled when in the context of HTML. After all, it only needs to do:

 string IHtmlString.ToHtmlString(){ return this.ToString(); }

This issue came up when I wrote my own basepage based on how the MVC Razor ViewPage class works, and I found that in addition to checking for IHtmlString in my write methods, I had to check for TemplateWriter to make sure the HTML wasn't double-encoded.

v3 now has a similar model for handling string encoding, and provides by default two models (although you can add your own). This is based around the new IEncodedString interface which is essentially synonymous with IHtmlString. We can't use IHtmlString itself as this would require adding a dependency on System.Web. The default encoding model is Html, using the HtmlEncodedString class, but you can specify no-encoding using RawString. There will be a blog post detailing these changes as well as a variety of other v3 changes soon.

Should we release Web-specific compatible templates, we'll consider having automatic translation from IHtmlString to IEncodedString if it is required.