With JSON owned entities, the root (non-JSON) entity is materialized and tracked, and then JSON shaper code materializes the JSON owned entity and tracks that separately; the change tracker does the fix-up etc. When originally implementing the shaper support for complex JSON, I also added JSON shaper code after materialization - similar to the owned flow - but that's too late, since StartTracking already gets called as part of materiailzation.

I considered separating StartTracking from materialization and pulling the former up, so that I can inject JSON shaper code in between - but that's quite a significant change would probably break external (non-relational) providers. Instead I opted for adding an extension hook during materialization, that gets called after the structural type is instantiated and its regular properties are populated, but before it's handed off to StartTracking().

Adding such a hook proved difficult - our shaper generation really isn't designed with extensibility in mind. The most problematic is that in relational, ShapedQueryCompilingExpressionVisitor immediately calls a separate private visitor - ShaperProcessingExpressionVisitor - which does most of the work, and occasionally calls into the "parent" ShaperProcessingExpressionVisitor. One of these calls is for structural type materialization, making it difficult to have the extension hook call back into ShaperProcessingExpressionVisitor, which is where the JSON shaper logic lives (and it relies on various global state inside that visitor, and so can't easily be moved out). So I ended up tracking the current ShaperProcessingExpressionVisitor on RelationalShapedQueryCompilingExpressionVisitor, so that the hook can call into it; and since ShaperProcessingExpressionVisitor instantiates and calls itself recursively, that also needs to be accounted for.

There's a lot of potential for simplifying and cleaning everything up here, I hope we get to it at some point.

/cc @artl93