Is your feature request related to a problem? Please describe.
Many WeakAuras with custom code abuse Custom Text and Custom Check utilities to make other changes to the aura. This is because there is no convenient solution for running a piece of code with state and region (of clones if applicable) context at an arbitrary, specified time whilst the Aura is active.

Alongside these hacky solutions not being what these functions were intended for there is another major drawback. They only have the option to run on "Trigger Update" or "Every Frame". This inflexibility likely results in many auras running code excessively in these boxes as there is no other convenient solution.

Describe the solution you'd like
A new type of Action that can be added to a WeakAura. This Action would have a code box to execute, with an option to run On Event(s), or every frame much like a custom trigger. This Action could have the same template as the OnShow and OnHide Actions. Ideally there would be a way to attach multiple different On Event(s) Actions to a WeakAura for more advanced interactions.
The Custom Code would have the state and region of the current aura (or clone if applicable) so that it can satisfy the requirements of making live updates to the Aura. An instance of this Script would be run for every clone individually. An option could be included to prevent the Action from running all clones if this is desirable.

Describe alternatives you've considered
This functionality can be replicated to some degree using a status trigger, a custom activation, conditionals with custom code blocks as results, and the OnInit function. The following is an example of this solution implemented on a basic bar aura tracker.
https://wago.io/NBgtgoskE
Note that a similar thing can be achieved with an event, only 1 condition, and no OnInit or custom aura_env variables. However, this relies on an event with a very short duration (E.g. 0.01s). As such this does not satisfy the requirements for a reliable alternative.
Whilst this alternative is functional, it is far from convenient.
In addition, running code in the Custom Text on trigger update or in a Custom Check does not satisfy the requirements as these blocks may be executed more than just on the intended event.

It is also possible to create an event hook in the OnInit, then attach this hook to each clone through the OnShow and remove in the OnHide actions, however this relies on the statefulness remaining correct. And as such may break in undeterminable situations.

There are other ways of triggering stateful updates within clones, however I wanted to implement an alternative that only uses basic WA functions, aura_env.state, and my own aura_env.variables, to ensure future compatibility.

How is OnEvent different from a trigger?

In a trigger you don't have access to aura_env.state or aura_env.region. E.g. I couldn't make a trigger that directly updates the colour of every clone created by another trigger (like in the example I provided)

That's not something you are supposed to do via custom code.

In a trigger you don't have access to aura_env.state

Maybe you are not familiar with Trigger State Updater (TSU)

A Trigger State Updater wouldn't have access to aura_env.region though, since the regions won't necessarily have been created yet. Also I got region:Color(r, g, b, a) from the "Common/useful Region functions" section of Editing Regions. It does state that other options should always be looked at first, but sometimes that's not possible.

You should not use region's functions directly, that's what conditions are for.
If your goal is to change region's color of all states you can do something like this in a TSU

function(allstates, event, ...)
  if .......... then
    for k, v in pairs(allstates) do
     if v.color ~= "blue" then
       v.changed = true
       v.color = "blue"
     end
    end
    return true
  end
end

in custom variables set

{
 color ={
    display = "color",
    type = "select",
    values = {
        red = "red", 
        blue = "blue", 
    }
  }
}

and set a condition to change your aura's color

So, why isn't it possible via conditions?

That works unless you want to generate the colour programmatically. You can do it with the Custom Check in conditionals, you just have to add some throttling, since it'll get called on every trigger update.
And you can only use a TSU if you are the one creating the clones. If you wanted to change the colours of clones produced by a default trigger then a TSU won't help you.

Don't worry about it, If you don't want to encourage people to manually edit regions anyway it's fair to not want to add features that make that specifically easier :D I get ya, just thought it might be an interesting addition.