Thanks for the links It seems that from the articles this is replacing the parameter server logic. I did see Thibault Kruse comments:
Subscribing to param changes via callback services is clumsy, so updates should be sent over topics.
Setting params over topics has the disadvantage that no feedback can be given (such as error codes), so services are to be chosen. The final decision is whether to use a single topic or individual topics for publishing current parameters and updates, and who is responsible for publishing.
A node param will be set using a service of the node. Global params will be set using a service of master. The node, after validating the param, updates it internally. After that, any interested 3rd party needs node to be informed of that change. The node publishes the updated set of its params on its own param state topic.
Is there a design decision for not having this an option (notification topic) and it seems that the topic name should be unique or follow the node name. For example, nodename_parm_event.vs parameter_event as a topic? It seems that generating a separate topic becomes messy when having a lot of nodes/topics in a network. Could the change event or flag be part of the node itself vs separate?