On a secondary, independent note, I'd like to bring your attention to a pattern that seems to show up a lot in JJ2+ scripting ("object" here refers to an instance of any API class):

• save object data
• overwrite object data with fake values
• run standard procedures on object
• analyze changes to object data
• restore object data
• modify object or perform other actions based on analysis.

Usually some of these steps are missing, but the general principle remains. Maybe players are actually kept completely outside the level but are temporarily placed into it so they can fire bullets and check masks and whatnot, and then transported back out. Maybe an object is temporarily given a different behavior or other properties so it behaves in a desirable way during a collision, etc.

I worry somewhat that the need for this pattern may reemerge when using this system, i.e. a particular custom object or other "add-on" may want to register a 2-phase hook with an "initialization step" (save and optionally overwrite data) and a "cleanup step" (analyze changes and/or restore data) surrounding all hooks from other sources. In the interest of supporting this approach, it may be a good idea to allow hooks to specify whether they are to run "early", "default", or "late". If multiple such modules exist, generally the least conflict-prone way to process them is to run cleanup hooks in reverse order as initialization hooks (compare: order of destructor calls in C++). A purist may also want any data that only needs to exist between the two steps to be locally scoped, which complicates the design somewhat. Whether any of this is actually worth the effort, hard to say.