I’m currently trying to understand what the result of NodeType.compatibleContent actually represents in terms of the data-model.
The current implementation is to check whether both node types are equal, otherwise to compare their contentMatches. That uses ContentMatch.compatible, where the current implementation seems like “check if there is any node type that is valid for this ContentMatch and the other one”.
To me, this seems like a content: "mirror code" and content: "mirror prose" would be compatible, even though that doesn’t seem useful for the way this check is used in applying replacements. I don’t think this is an issue with any of the standard schemas and I’m not nearly experienced enough with the codebase to manually fuzz an example where this could cause bugs.
I’ve tried this with the simple schema from the previous paragraph (without using any groups) and that seems to confirm the assumption that any nodes after the first one aren’t relevant for compatible.
I’ve looked into the commit history for that inner function, and it seems that code was last touched with the “Start moving to new content expression system” commit which made the content expressions more powerful. Before that, compatible was a recursive function which seems more appropriate.
So my question is: What is the purpose of this function, what information does it provide to the Node.replace implementation? Could this be a subtle bug or am I just missing something?