I'm not on the ASP .Net team but I am on the VB team. Anything I say on this, though, is pure speculation.
VS is a complex eco-system. Something that seems simple to fix from the outside may not be that way on the inside and things that look complex can be really tough to change. Also, since every version of VS .Net targets the same version of the CLR that it shipped
with and only that version, we have available all the new whiz-bang features of the CLR as well as access to all the work done by other teams (if ASP .Net writes a cool uploading subsystem that handles http, ftp, unc, local, etc. and offers a nifty new browse
dialog then other teams my use that component). VS is very interconnected and makes use of MS development technology pretty extensively.
What I'm getting at is you don't know how many of these new features the improvements in HTML formatting used. If it's written in managed code (which I would guess that it is) then it could use generics, anonymous methods, different access level properties,
etc. Maybe it takes advantage of some new .Net libraries that are only in Whidbey. Porting it back to 2003 could not only be hard, it could be impossible.
Also, remember that at the end of the day we are selling a product and we have to get that out the door. If the ASP .Net team took a month and back ported this feature then they would either start slipping on our release date or be forced to drop features from
Whidbey. Also, the more features we backport the less incentive people have to move up to Whidbey. If we backported this (assuming it was possible) then the floodgates would open; why not backport Master Pages? Snap lines in winforms? DataGridView?
I think that everyone wins if we backport the critical stuff but focus on getting the next version out the door. I don't make these kinds of decisions but this seems to be feature level work rather than a bug fix and features usually belong in new versions.