Yet another interesting aspect is the decision to use a combination of heuristics and signature matching to identify XSS attacks, with the heuristic methods being used to compile and add to the signature database in use. If designed correctly, it could allow users to share and modify their signature database to include defence against XSS attack methods they haven't already encountered. Microsoft could use reports from users to compile a core signature collection that is then updated with the monthly security patches, much as the Malicious Software Removal Tool is.
Microsoft's efforts are to be commended, however with reality being somewhat hostile, Internet Explorer users should not fall into the trap of thinking that the in-browser XSS filter will protect them against any and all potential issues, much as they shouldn't with the many and varied in-browser anti-phishing initiatives that are in use. This is something that is acknowledged in the SVRD post, both in terms of the type of XSS attack to be targeted (basic reflected XSS) and in terms of what will not be protected against (such as the many other XSS methods).
If you take the approach that it is a backstop against accidental user mistakes, then the filter will have a long and useful life and should form part of an integrated defence posture. To achieve this, the development team need to minimise the deviation from the desired design conditions and ensure that the filter doesn't annoy users to the point that they will willingly turn it off to regain normal browser or site performance.
If the development team can deliver a viable solution, it is something that other browser and rendering engine developers should pay attention to and consider implementing their own similar solutions.