To be able to more easily target new messages without making in-product changes, it would be great if we supported many of our existing message-passing/notification APIs as AS Router triggers. This could have allowed implementing bug 1570372 without writing any code in the tree. You would still want to be able to use JEXL on the message/notification to be able to filter them.

Example listeners/observers:

• Observer notifications
  • Inputs: notification name/string
  • properties given to the JEXL for targeting: subject, data
• Actor/message manager messages
  • This is easy with the message manager but that is being replaced by actors which AFAICT don't currently have a way to listen to messages from outside of the parent actor and don't have the hierarchy to allow listening to all messages for a window/process.
• Telemetry events/histograms (I don't think they have a way to listen for accumulations yet so currently you'd have to poll which is inefficient but in theory this could be added)
  • Input: event or histogram name
  • Properties given to JEXL for targeting: histogram bucket, event extra data, etc.

Maybe this idea isn't so great without support for actor messages but maybe that's also something we could add? It's kinda too bad we lost the bubbling of messages with actors.

I think a good first step is adding observer notifications support. It's a fairly common pattern that could benefit a lot of different features. It would also help us remove some of our existing trigger patterns that are doing very similar things.
It would be good to have a generic observer listener (maybe a preference one too) that offloads the filtering and decision making to the targeting expression to get the most out of it.
The other usecases seem to need more careful consideration, we might alternatively want to look into more flexible templating (this is currently waiting on Fluent support bug 1616280).