I have no remarks with the code here (nor did I check it). But I want to propose the following merge strategy:

• Hide new nodes from UI.
• Merge.
• Implement the draw changes for diff. flows/sockets.
• Implement warning propagation for old nodes.
• Hide all old nodes that will be replaced/upgraded.
• Bring in new nodes (so the menu will get considerably small).
• Keep bringing more new nodes.

The hiding of the new nodes can happen using an experimental flag.

The rationale is that I think we should avoid having the old and the new system co-existing more than we have to. That would leave Blender in a unreleaseble state for too long. Developing only in a branch also has its downsides.

With this approach the worst case scenario is to release 3.0 with a sub-set of the nodes. Not ideal, but acceptable.

In theory we could flip the nodes visibility (show new ones instead of old ones) after all the new ones are ready. It depends on how long we will get this done. This is a decision we can have it later too, depending on how long the other targets (draw changes, warning system) take.

Finally, as you can see from my list, I think the experience of fields should be good from the get go. People should be able to tell them apart from the nodes they are used to. The legacy node(-tree)s should be blatantly visibly different than the new one. I think this approach will bring more clarity to the users and will allow more people to test it properly from day one.