In my opinion, very bad idea is to keep and update information about all process and deployments versions in event bus.
Keeping that in database is better, but still not very good.
we solve a similar problem like yours as follows:
We update our process definitions regularly and needed a mechanism for only starting new processes in the newest version (while older processes keep running in parallel until they die out eventually).
We created a table in the database, with all existing process definitions. Each one has an end-date (which is set when a newer version is deployed or can be null if it is the newest one), and we created a service (used for starting new processes) that returns the name (in your case the deployment-id) of the currently up-to-date process definition.
About signaling: We dont signal to the session, but to processInstanceId's. If you want to signal to all of your running processes across all deployment id's, you could use this database table and find out which deployments are existing.
Maybe there is a better way, but i hope this helps.
We are considering to extend REST API and do this at jBPM side, not in our environment. Currently we stuck on building kie-wb from sources.
We also have some ideas for new services which could be usefull for others.
extending REST API is one way to go but please keep in mind that it might be rather heavy operation and then it will block the thread that issues the request (one of your event bus threads I believe). Why I see it as heavy operation is that it will need to first figure out what deployments it has calculate which one is the latest and then find out what to signal - depending on runtime strategy it could be as simple as just taking rutnime engine and then kiesession and signal it (singleton) but for per process instance you need to find out what process instances are waiting for such event.
Alternative solution which I would personally go with is to great another project with process that will be capable of doing all this things as it has access to all services of the platform via CDI (either direct CDI via API or regular beans - this will require addition of jars into the jbpm console war). Moreover you can benefit from the async behavior to not block any threads incoming. So event bus just submit a data to that process (starts it) and then process does all the heavy work for you. You can have as many instances of this management process as you like running in parallel. Then the process can star/signal new process instances from within it.