Right now user code that wants to add a slot to both globals and non-globals has to use different slot indices, so has to branch every time it wants to use the slot. This is at least biting Paris bindings. Jason suggested that globals should work like functions: some small number of slots at the front are reserved for API consumers, then come the slots the engine uses on globals, and if you want more than the pre-reserved number of slots, they go after the engine slots. In fact, XPConnect is already depending on the fact that the JS engine never uses slot 0 on globals (because it's the original constructor slot for the "Null" class). Doing this would, of course, require hunting down all the places in the engine where we touch the global's slots and adding this compile-time offset to them all... But past that, there should be no slowdown; just a slight bit more memory usage per global.

Once the change underlying bug 755186 is fixed, I think we can just make globals not need pre-reserved global slots, in which case global classes could just use the normal JSCLASS_HAS_RESERVED_SLOTS(n) mechanism.

New summary is what I think Jeff and I decided we should do.