I’m leaning more towards putting it in definitions. Reason:
I’ve also often created operations right in the patch, as it’s convenient to see the operation patch right where you use it.
But often, you have to copy/duplicate a node definition, and if there are definitions inside, it duplicates the definitions but still references the old definitions in the old definition from which you made the copy. That’s a major point for confusion.
The point for beginners is also valid.
Another point is the unintended undo that will undo changes in patches you don’t currently see, if you have definitions in a patch and they have changes inside of them. That’s quite tricky, and you often don’t understand what happened, and then a day later think, hey, I’ve fixed that already, did I forget to save? No, you pressed undo in the patch where the definition lies…
Even though I’d personally instantly set it to put definitions in the current view, I agree that the behavior should be consistent for newcomers and follow whatever the Node entry in the node browser does. Realizing now that having different behaviors there can be super confusing.
It’s true that it’s also a nice introduction to the Definitions view, and tells the story that when you create a definitions it “should” go to definitions land.
But if I may share my personal experience there, I often felt tortured when learning gamma believing things should be done in one way, or that you have to rigorously follow pattern A, B or C. It’s only quite recently that I realized that whatever works works, and by works I mean:
Easy to scale
Easy to maintain
Easy to figure out what things are about when re-opening patches three months later
And if that means putting definitions outside of the definitions patch so be it, or if that means taking only bits of a specific design pattern but skipping the rest because it’s overkill/irrelevant/whatever, so be it.