Re: don't cache ASP.NET controls, it bears repeating. Here's another example of why you shouldn't cache ASP.NET control instances or store them in session state - ASP.NET Memory Issues: High Memory Usage with AjaxPro [blogs.msdn.com/tess].
The HtmlAnchor class can resolve virtual paths if you use the HRef property but can't if you set the attribute via the Attributes collection, I think. Definitely, it has screwy behavior, particularly if you're trying to use named anchors, e.g., <a href="#foo">Go to foo</a> and <a id="foo">Here's foo</a>. ASP.NET overriding the id attribute for its own purposes particularly sucks for this HtmlAnchor use case and is one of many reasons I am getting sick of WebForms. I love the low-level ASP.NET/IIS platform, but I'm looking forward to booting WebForms as soon as ASP.NET MVC is golden.
I like the mvc and I use it now a lot more than webforms and I can't say I've had any real problems considering you can really fix bugs yourself atm if needed.
The only thing I don't like is that its still using a lot of asp.net, it uses the webforms page base http handler, which is great for transitional stuff, but theres a hell of a lot of crap code in asp.net thats there to suit webforms operations..
I'm certainly not excited about the monolithic extension methods approach to rendering html either, I really want them to do a new httphandler and page base and control architecture, something thats much more evolved and designer inolved like webforms is.. I also want some really lightweight control requirements.. like even to the degree that the rendering is reliant on a single interface thats maybe something like:
void Render(HtmlTextWriter writer);
You can easily abstract a control system on top of that, and more importantly jump out of that and do really lightweight controls.