Re: debugging interfaces

After a quick look into this PDF (very instructive, thanks), I think I understand the advantages of having a mirror API that is clearly distinct from the rest of the ES API.
However, ES already has a number of reflection features built in, that are clearly not stratified. From the prototype and constructor property, for...in statements that allow to list properties, typeof, instanceof, including new ones like the functions to __define / __lookup a Getter__ / Setter__,

including the actual stack traces API (like the Mozilla Stack object https://developer.mozilla.org/en/Core_JavaScript_1.5_Reference/Global_Objects/Error/stack).

Also, there are a variety of environments a JS "thread" can run in today. For browsers, it may run in an HTML page, or in a Web worker, but it may also run in a command-line interpreter, and even as a server-side language. Will all those need different ways to get JS threads for examination ?

As for the browser, for example (sorry, it is by far the environment I am most familiar with), I think it would be nice to still allow a page to access this mirror API to "explore" another page, without needing explicit user consent under certain conditions (like a same-origin policy for the inspector / inspected page, for example). Test suites come to mind.
Would this kind of things be acceptable, from a security point of view ?

It *seems* Opera Dragonfly is using some kind of "Scope" thing as its mirror / proxy API (http://dev.opera.com/articles/view/opera-dragonfly-architecture/), and then the rest is pure web (Opera developers' insight would be welcome on that matter).
However (still about the browser), even the proxy part can be moved to pure web technologies (like XHR, through some server), in a debugging lib. That would leave only the mirror API to define in the standard.