Currently the nodes rely a on hard-coded dbus instance: either the default system dbus, or an environment variable pointing to a "dbus over tcp" instance. While that does work for many people, it is frustrating and very limiting for people who have multiple systems where each would require a separate node-red installation. People like myself, already have large automation systems that integrate node-red, home assistant and esphome with smart sensors and devices. In this situation, it makes sense to integrate the venus devices with the existing node-red instance so that it simplifies the logic for controlling your power generation dependant on existing sensors - like, for example, switching to grid when a well pump is needed that would otherwise overload the inverter, or only running a device if SOC is more than xxx.

I have multiple victron systems, so maybe I am an edge case, but it makes sense to "bite the bullet" now and introduce Configuration Nodes to control the venus instance that the worker nodes are referring to. The node could allow selection of the system dbus or an IP address and port of another instance of venus. Multiple Configuration Node instances can then be defined to handle multiple venus os instances.

Node Red provides the ability to define configuration nodes and this feature is used by many node developers.
Configuration Nodes

It is possible to glue multiple systems together via a MQTT server or other middleware, it makes it more complicated than it needs to be and harder to maintain for many people.

For your consideration.