Thanks @marcus-j-davies !
That's my preference as well, enabling me to avoid scope issues and be able to pass less arguments in my inner workings.
My concern is whether by modifying a framework object (node) I will not be stepping on anyone's toes, or that some framework code may impact my properties...
The node instance is isolated - there is no overlap elsewhere unless you deliberately target global.
However, as your (if your) code gets larger and more complex, you may wish to refactor it into other modules. At that point, you will be glad you added the variables as properties on the node instance's this object (which most people interpret as node) since you can simple pass this as a reference to your module functions/methods.
You will see that the export is on a separate line so that it gets a named function. Then the exported function calls a setup function and registerType, nothing else. The registerType includes nodeInstance as its callback so that you don't get confused by which bits are part of the overall module and which are specific to the instance. nodeInstance does the usual things except that it does not create the unnessary node variable. However, wherever this is passed to another function/method, the receiving function always calls it node.
The other thing of note is that I create a module-level (think of that as the "local global" ) object to hold data for the module as a whole but that may still need to be passed to other includes. Things like the name of the node for example.
The numbered comments in the code show what order things happen in so there is no confusion.
This approach really helped me get to grips with the order of things and with the isolation/availability of variables.
But that isn't the same at all. You are not setting values on the node instance but actually in the Node-RED context store (albeit in the area dedicated to that node). That context store could be set up differently on different Node-RED instances. So it might, for example, be set for persistent storage. While that might be what you want, it may well not be.
So you are not avoiding scope issues, you are merely swapping one set of considerations for another.
Oh, and of course, the context store can be examined by anyone with Editor access. Again that might be helpful or it might not be.