these scripts operate on host level, and event id is quite different - it makes sense for an alert, as that is based on the event.
how could it work for a host ?
I understand what you mean as it wouldn't make sense to add event data to a host-only interaction, however my idea was to extend the functionality for those scripts, so they could be more powerful. In my case, for example, I need to use history data for the specific event the alert is raised. I already have an regular action set for those events, but there are cases when I want to have an ad-hoc test run, pretty much like a ping test, to help troubleshooting. Surely I have other tools to perform the test, but it would be great to have a central location in Zabbix.
Of course exposing a bigger set of macros like items, triggers and history might not seem plausible, but most likely there is an event associated to the availability of the little context menu where the scripts appear. By using the event id we can script something that will gather the information we need using the API and then process that the way we need. We just need something that would correlate with the trigger that was raised, so I thought the easiest and simplest one would be the event id.
but what if a host has 10 active triggers right now ?
it might make more sense to support EVENT.ID and related macros/variables in map urls, then you could use them on trigger elements instead (but i still don't see a nice way to use them on hosts)
well, long term there could be a feature where clicking a host with problems opens a list of all active triggers right there, and then trigger urls would work on any of them with EVENT.ID etc... but that's a more serious redesign 
You could make the trigger name link a sub-menu for possible actions, one of them being opening whatever is in the URL field for the trigger, then the frontend scripts. Pretty much the same way it happens when clicking on the host, there would always be a menu.
I understand it's probably a more serious redesign, but I think it could be a nice feature. And of course then more macros could be exposed like TRIGGER.ID, ITEM.ID and so on.
when you say "trigger name", what do you refer to ? i hope not the problem name that is displayed below host element if there's one problem only.
having event related macros/variables for trigger elements on map seems easy enough and useful. on hosts - that might be the complicated thing.
I mean the trigger name as when it appears in Monitoring>Dashboard (under "Issues") or Monitoring>Events (under "Description"). Although we use maps (and the problem name feature) it's normally on a big screen and no one interacts with it, so I'm not thinking on using the new feature on maps.
On the Events page, you already have a sub-menu available which contain trigger and history related actions, so it could have a scripts portion as well.
other macros have been asked to be supported in global scripts in these issues :
ZBXNEXT-1406- HOST ID- ZBXNEXT-1507 - TRIGGER.ID
ZBXNEXT-2837- inventory macrosZBXNEXT-3209- user information (username, name, surname)
With Zabbix 6.4 (See ZBXNEXT-3496) the macro {EVENT.ID} is now exposed in global script "url" and "confirmation" fields for manual event actions. They can be seen in context menus events/problems.
I think nothing more can be done here.
Closing the issue as duplicate of ZBXNEXT-3496.
If you feel like something is still missing, feel free to reopen the issue.