Is your feature request related to a problem? Please describe.
It's generally advised to avoid using the same custom event name for multiple unrelated WAs since ScanEvents will perform unwanted cross-firing. However, for a custom WeakAura that is used as a template and duplicated frequently (e.g. custom templates for class spells or raid mechanics), the duplicates will have the same custom event name unless manually changed each time.

Describe the solution you'd like
In addition to the existing WeakAuras.ScanEvents() API, a new function WeakAuras.ScanEventsForAura(id, ...) can be added which will only scan triggers for the specified WeakAura id.

Describe alternatives you've considered
The existing workaround is to pass the id of the intended WeakAura recipient as an event argument, and filter on that in the trigger. However, this adds overhead associated with activating the aura environment and running the trigger, and the overhead scales quadratically with the number of WeakAuras using the same event name (assuming they fire at similar rates). The designer of a template-style WeakAura doesn't know how many times users will duplicate it, causing a scalability concern.

Adding this new API would eliminate any potential scalability issues and also simplify the WA code by removing the need to add an id argument and compare against it in the trigger.

No, that's out of scope. The functions are internal, they can and are used by custom code, and thus we won't change them within an retail expansion. But they are still internal functionality.

I can accept not wanting to implement my suggestion but this rationale doesn't make sense to me. I think most WA authors would consider ScanEvents an integral part of the API available to them, since it's the only way to generate a trigger update without a game event. If ScanEvents is an "internal function" then that raises the question of what the intended public API is for programmatic trigger updates.

They would be wrong about that then. There's no public api for that. There's internal API, that we have choosen to not break.

Will there be an officially supported public API for custom trigger updates in the future then?

If we were planning changes to those functions we would consider what kind of backwards compability functions we need.