At this time, the RepositoryNodeTypeManager assumes its cached node type model will be changed directly through its API, but should instead observe the appropriate "/jcr:system/jcr:nodeTypes" branch for changes and dynamically update its cached node types. In a clustered environment, the node types can be updated in one process (ultimately via the RNTM) and this will update the node type definitions stored in the graph, but the RNTM instances in the other processes within the cluster need to respond to those change events and update their cached representations.

I do not believe there is anything in the JCR 2.0 specification that specifically addresses how the node type definitions in a session or workspace should behave with respect to the persisted data. This is likely because all of the properties on the built-in node type definitions corresponding to the storage of the node types (see Section 3.7.14) are protected, meaning clients may not update these stored node type representations directly. The ModeShape implementation definitely adheres to this design, but one RNTM instance in a cluster will internally update its cached node type model and the stored graph content. This change in the stored node type definitions will be represented as events in the clustered observation manager, so other RNTM instances in the cluster can simply watch for these events and dynamically update its internal node type model.