I wonder if we are over-thinking this. An update against this entity will always hit the root table first. That acts as a block between T1 and T2. E.g., consider a schema with persons (Person root) and crm_pers (Person secondary table) tables.

P1 updates persons and acquires a write lock. P2 will be blocked as soon as it tries to update persons as well. So I'm not sure the optionality of these secondary tables has any role here.

I think its safe enough here to simply say that compliance means we omit the table-span check at all.

Andrea Boriero - optional indicates that that no-row in the secondary table is interpreted as all null values. We may handle it that way on save, cannot remember exactly