`XPCOMUtils.defineLazyModuleGetter(this, "SomeName", …)` is a very common pattern to reduce memory usage for modules which aren't always needed. I understand that `this` refers to the per-tab global, not the "special per-script object". So the problem is that many frame scripts are attaching the lazy module getter to the per-tab global (thus polluting that namespace) when they're usually only needed within the script file. It seems like having `this` refer to the "special per-script object" and having a separate `tabGlobal` object available would have avoided this problem and been more natural IMO. Why is it done the way it is? If we can't change the meaning of `this` to be less of a footgun or provide a name to reference the object where frame variables are defined (to use with defineLazyModuleGetter in place of `this`) then we should probably audit the code to find unintentional scope pollution. For example, here are a bunch of uses of defineLazyModuleGetter with `this` in frame scripts: https://dxr.mozilla.org/mozilla-central/search?q=define+this+file%3A%40content+-path%3Atest+-path%3Ab2g+ext%3Ajs&redirect=false  https://developer.mozilla.org/en-US/Firefox/Multiprocess_Firefox/Message_Manager/Frame_script_environment
My current patches for bug 1186409 actually change this, for .jsms. What is needed is to change the case for NonSyntacticVariablesObject in js::GetThisValue() to return the NSVO, rather than recurse into enclosingEnvironment(). My understanding (which may be wrong) is that the current behavior for frame scripts is needed for addon compatibility.