add surfacing ScopeCeiling to open questions

Author: naugtur

.npmrc

@@ -1 +1,4 @@
 package-lock=false
+ignore-scripts=true
+git=false
+allow-git=none

refactor.html

@@ -129,14 +129,25 @@ would depend on the provider of `ScopeCeiling` adding them.
 
 ## Open questions
 
-- Is `NewModuleEnvironment` a spec fiction? Can we verify that `ModuleEnvironmentRecord` points to its `OuterEnv` explicitly as opposed to it being looked up by default in the end?
+1. Is `NewModuleEnvironment` a spec fiction? Can we verify that `ModuleEnvironmentRecord` points to its `OuterEnv` explicitly as opposed to it being looked up by default in the end?
 
   - This [area in Firefox](https://searchfox.org/firefox-main/source/js/src/builtin/ModuleObject.cpp#1598) seems related and [this line](https://searchfox.org/firefox-main/source/js/src/vm/EnvironmentObject.cpp#408) looks like a match for spec setting `OuterEnv`
   - This [line in V8](https://github.com/v8/v8/blob/main/src/heap/factory.cc#L1709) mentions `outer` in the context of `ModuleContext` - might be related 
 
-- Depends on an umbrella proposal to have an entrypoint to defining a ScopeCeiling, so likely will be folded into a Compartment proposal or its subset.
+ ---
 
+## Open questions
+
+2. `ScopeCeiling` needs means to be associated with a module. 
+
+- We are open to exploring exposing it independently of Compartment, as some of the motivating usec-ases (e.g. DSLs) do not require an importHook to also be present.
+  - Is `import('specifier', { scope: {} })` an option?
+  - An entity encapsulating a pair: `ModuleSource`, `ScopeCeiling` and also be acceptable as input whereever ModuleSource is?
+  - Open to fedback and suggestions.
+
+- Regardless, the Compartment proposal would define a common `ScopeCeiling` for all modules loaded in a `Compartment`
 
+- If we don't find a useful way to surface `ScopeCeiling` on its own, we will fold this proposal into refreshed Compartment proposal.  
 
 
 ---