The JCR specification talks about autocreated properties and child nodes in Section 126.96.36.199:
An item may be declared auto-created, meaning that it is automatically created upon creation of its parent node.
and then in 188.8.131.52.1:
If an item is auto-created but not protected then it must be immediately created in transient space when its parent node is created. Creation of auto-created non- protected items must never be delayed until save (see §10.11 Saving).
ModeShape follows this behavior when nodes are created. But in your case the node types are modified after the node is created, and I don't think the specification really addresses this case at all. ModeShape does not look for auto-created properties or child nodes upon save, simply because of the overhead (and because it's not address).
However, I'm open to suggestions for how we might address this. One option is to do the extra work on Session.save() that would affect everyone. Another option is to add a ModeShape-specific method (via our public API) that would re-validate a given node when the application wanted to use it.
I guess I am most interested in making sure that node definitions can evolve with time without having to add boiler-plate code to deal with data migrations. I guess in this particular case, it can be argued that when creating nodes/properties below the auto-created child node that the system should respect the autocreated tag and automatically create the necessary node and/or when reading the autocreated child/property that the system should auto-create those too. I think both needs to be there for the system to allow node definitions to change without having to ask the user to do anything in particular to existing data. I am not sure whether the idea of "reading causing writes" would be a good idea though, perhaps the read would simply create pseudo nodes/properties that would only be persisted if need be (e.g. when the property or node is actually changed and a save() occurs).