We did consider this before, but with the new browser controller I don't see a huge win with this.
We are already have full coverage on IE9, and we will be able to repurpose some of the IE9 machines when we get the dart2js compilation service set up on the buildbot.
What would we be trying to accomplish with this? Developers would need to do local registry modifications to enable this.

This would make it easier to run benchmarks on IE.

When you don't need the DOM using cscript.exe is nice because it is headless. Running Internet Explorer through VNC on a virtual machine in some remote data center is not a great experience.

I'm not actually arguing for adding new buildbots that test Windows Scripting Host, but I think it sometimes might simplify investigating IE test failures if we had a convenient way to run the JavaScript engine from the command line.

It's rather easy to create a file that adds the registry entry, and it can be automated using cscript.

OK, I misunderstood then, thanks for clarifying.
That sounds like a good idea.

I have been playing around with another solution for this in my head though - I would like to add remote support in the browser controller, i.e., a small server running on my windows machine - it can fire up IE instances that will run against the test.py http servers running on my linux box and ship back the results just like we do now. This can be extended to a multiuser approach, where multiple users can utilize the same windows (or another os) machine for easy testing of in browser stuff, getting back the output easily. This probably does not eliminate the need for windows sessions completely for debugging, but will be more than sufficient most of the times, e.g., I have a fix that I think will make this failure go away on IE -> just run it on directly from your linux/mac command prompt through the testing scripts.

Set owner to @ricowind.
Removed Priority-Unassigned, Area-Test labels.
Added Priority-Low, Area-Infrastructure labels.

Added NotPlanned label.