As described in our paper https://github.com/amb26/papers/tree/master/ppig-2016a , a desirable feature of an authorial system is to keep isolated records of the user's constructional intention. This allows the process of construction to be separated from the process of designating construction. Keeping these records would also allow us to solve issues such as FLUID-5614 ("double deep trees"), FLUID-5028 (continually arriving subcomponents) and FLUID-6146 (multiple createOnEvent components for the same event), as well as preparing the ground for crucial requirements like FLUID-6147.

In the PPIG paper, we named this realm as "potentia II" to distinguish it from the existing realm of designating potential effects, the grade registry.

Our potentia II records need to be indexed by path as well as by sequence, as well as permitting multiple transactional records to be active simultaneously, designating components which must be considered non-interfering until their construction is complete. The concept of "complete construction" would be represented by a dynamically maintained queue of "fully reified components" - for example solving FLUID-6146 by populating the inventory of createOnEvent components fully in advance (forming a single transaction), or FLUID-5028 by enqueuing any further children of the same constructing root.

We decided to solve the issue of component destruction by prohibiting any component destruction during a construction transaction (as suggested in FLUID-5499) - a destruction operation must form its own, separate transaction. It's possible that in future we may support the aggregation of sequences of such transactions into "mega-transactions" allowing arbitarily complex operations on the component tree from being presented as a single atomic unit for the purposes of observation by other component tree citizens. This would be necessary in more mature Nexus applications, and would require explicit transaction demarcation to be supported in its wire protocol.