Is your feature request related to a problem? Please describe.
Often I would love to minimize the amount of custom code, that I have to write, if I could better integrate or use already implemented default triggers. For example during the progress, I was asked to make a WA that is triggering when the disc presses Evang to show a list of all alive raid members that do not have Atonement buffed, so that other healers could explicitly focus on them. The custom code for it, is not complicated, but by pure QoL view, it would have been nice to use the UnitHealth (>0) trigger for the alive members, the aura2 trigger for the missing buff as well as the default combat log trigger for the Evang cast event.

Describe the solution you'd like
According to the missing atonement WA described above I would love to have two features:

1. Getting informed, whenever another trigger changes its state (combat log trigger in the example)
2. Having access to collected states for data access (aura2 & health triggers in the example)

In my head, without checking any of the capabilities, I imagine the 3 default triggers to be sub triggers only available on custom code triggers. Those you can give names to further work with them. This would avoid to constantly write a custom trigger condition, even tho it is not much effort. To get informed when the states changes I was thinking of a new WA internal event, which you can then filter by the subtrigger name like you can do with unit triggers (i.e. DATA_PROVIDER_UPDATED:evang for the combat log trigger named evang). For the data collection part, I would love to directly access those collected states with something like aura_env.dataProvider.alive (i.e. for the unit health trigger). This would minimize the amount of code to write for the same task every time, collecting and saving the latest states of a sub trigger.

Describe alternatives you've considered
@asaka-wa already made a quick pull request inspired by this feature idea, so everything described here is now only quality of life, if the corresponding pull request gets accepted (#3699). Which would be enough for invested custom coders, but may be not transparent enough to get more ppl using this feature.

Additional context
This whole feature request is intended to minimize the amount of code that needs to be written by WA creators and to re-use as much of already existing code for them, which was already written by the WA devs and which is well tested.

I made a mockup by cutting & combining multiple screenshots of WA's that I have to show off, how I could imagine the setup of those data providers (sub triggers).