Bugzilla

I digged into this a bit more after briefly discussing about it with Shane yesterday.

Given that I'm unable to reproduce the issue anymore (and I don't yet see why), I opted to manually verify which conditions may be able to trigger that issue in practice (hopefully based on this I may get some more ideas about how was it reproducible, and suddenly it wasn't anymore).

Based of the manual verification I did (described in more detail below):
- the two conflicting experimental APIs have to be part of the same privileged extension
- that error should be triggered if an API does define Services using `var { Services } = ...` first and then an experimental API loaded after that one does use `ChromeUtils.defineLazyModule` directly (and not through the XPCOMUtils helper).

------

Manually verified cases: 

- as I was originally assuming, **a privileged extension's experimental API cannot introduce a conflict like this in an experimental API part of a different extension** (and it can't introduce the same kind of conflict with a natively integrated API, and the opposite is also true).

- **a privileged extension's experimental API can introduce that kind of conflict with another experimental API that is part of that same privileged extension**

- `var { Services } = ChromeUtils.import("resource://gre/modules/Services.jsm");` does create a `Services` property that isn't configurable (verified by looking to the property descriptor retrieved using `Object.getOwnPropertyDescriptor`)

- `const { Services } = ...` has different scoping behavior from the scoping that `var { Services } ...` does have, technically Services doesn't become a property of this but a binding in the lexical scope

- if `const { Services } = ...` is part of the experimental API loaded first, and another experimental API loaded after that does use `var { Services } ...`, a conflict it is triggered by with a different error message: `redeclaration of const Services` 

- if `var { Services } = ...` is part of the experimental API loaded first, and another experimental API loaded after that does use `ChromeUtils.defineModuleGetter`, that does trigger the error `TypeError: can't redefine non-configurable property "Services"` (when `chromeUtils.defineModuleGetter is being executed)

- if the second experimental API does use XPCOMUtils.defineLazyModuleGetter/Getters, the same `TypeError: can't redefine non-configurable property "Services"` error will be trigger but the stack trace would differ (because the error is thrown from XPCOMUtils.jsm and not the experimental API module)

I digged into this a bit more after briefly discussing about it with Shane yesterday.

Given that I'm unable to reproduce the issue anymore (and I don't yet see why), I opted to manually verify which conditions may be able to trigger that issue in practice (hopefully based on this I may get some more ideas about how was it reproducible, and suddenly it wasn't anymore).

Based of the manual verification I did (described in more detail below):
- the two conflicting experimental APIs have to be part of the same privileged extension
- that error should be triggered if an API does define Services using `var { Services } = ...` first and then an experimental API loaded after that one does use `ChromeUtils.defineLazyModule` directly (and not through the XPCOMUtils helper).

------

Manually verified cases: 

- as I was originally assuming, **a privileged extension's experimental API cannot introduce a conflict like this in an experimental API part of a different extension** (and it can't introduce the same kind of conflict with a natively integrated API, and the opposite is also true).

- **a privileged extension's experimental API can introduce that kind of conflict with another experimental API that is part of that same privileged extension**

- `var { Services } = ChromeUtils.import("resource://gre/modules/Services.jsm");` does create a `Services` property that isn't configurable (verified by looking to the property descriptor retrieved using `Object.getOwnPropertyDescriptor`)

- if `var { Services } = ...` is part of the experimental API loaded first, and another experimental API loaded after that does use `ChromeUtils.defineModuleGetter`, that does trigger the error `TypeError: can't redefine non-configurable property "Services"` (when `chromeUtils.defineModuleGetter is being executed)

- if the second experimental API does use XPCOMUtils.defineLazyModuleGetter/Getters, the same `TypeError: can't redefine non-configurable property "Services"` error will be trigger but the stack trace would differ (because the error is thrown from XPCOMUtils.jsm and not the experimental API module)

- `const { Services } = ...` has different scoping behavior from the scoping that `var { Services } ...` does have, technically Services doesn't become a property of this but a binding in the lexical scope

- if `const { Services } = ...` is part of the experimental API loaded first, and another experimental API loaded after that does use `var { Services } ...`, a conflict it is triggered by with a different error message: `redeclaration of const Services`