Obviously, the nodes I am most familiar with are my own. Though I do have my own way of working with nodes that I find far more suitable for me than the "standard" way shown in the docs.
The uib-tag node in uibuilder is an example. It has multiple typed inputs most of which allow msg.* and so have to be processed asynchronously. Which means that the input message handler for the node also needs to be async.
Note how the input message callback fn is async and so must call the done() function when it has finished. Also note how I process all of the typed inputs in parallel using promise.all. And that I use a standard function, getSource which is in one of my standard libraries:
The nearest I can offer for that are my test nodes.
I use these to test out how Node-RED processes nodes and how I can improve my understanding and write better nodes. You can clone the repo and then run your own tests if you like.
Note though that this does use my own way of working, as mentioned above. I think that, at least for the node runtime's, this makes it a lot easier to follow the different operational phases of Node-RED (initial startup, instantiation of a node instance, receipt of a message, etc.) but that might just be me.
The Editor panels are also broken out into separate files to make it easier to work on them in VS Code and with ESLINT but the structure is a bit more complex.
Then you also have an example of using a common library to support the Editor panels of all the nodes.
Though I do have my own way of working with nodes that I find far more suitable for me than the "standard" way shown in the docs.