You don't say why... Is there some aspect of "Leader Key" that you think is not as flexible as it could be? What advantages would KM offer? One aspect that crosses my mind is that a solution in KM could probably give finer control of which commands are available in a given context, and I give an example of that below.
Why are attractive visuals important? The ideal interface is one that you hardly notice.
Not everyone here will agree, I know, but I think it is important to have the first trigger key bring up a safe input area of some kind (there are several possible choices).
@phario, here are two methods that I use that may overlap a little with the Leader Key idea. #2 is closer to what you intend, I think...
Method 1: using Trigger macro by name
In the topic 'How I limit which macros are listed by "macro by name"', I included the following example of how the kind of things that can appear in the list.
Hit the trigger key (you gave the example of ⌘-space), then type the two characters that call the macro (these characters are at the start of the name of each macro).
Possible negatives compared to Leader Key include:
- It is necessary to hit "Return" (or "Enter") after typing the pair of characters, e.g.
⌘-S, B, S, Returnfor your Safari example. - Err, I think that's it, in practical terms, although maybe you won't like seeing other macros that have "sb" somewhere in their name also being present, further down, in the list.
Possible advantages over Leader Key may include:
- If you mistype, you have the chance to correct before hitting Return.
- The only macros that can be triggered are in currently active macro groups, so you could, say, have "BS Bookmark and Save" in the list only when you are using Safari, and "BS Safari..." active when you are not using Safari. So you get to reuse "BS".
If any of that sounds interesting, you might want to jump ahead to the "Conclusion" section of 'How I limit which macros are listed by "macro by name"' first, for a summary of my quirky way of setting it all up, which I still find suits me best.
Method 2: using conflict palettes
My previous method was to use conflict palettes, and I still use that method in some circumstances. For example, I have a trigger key that I use as standard for helper macros that are specific to the current application. When using Safari, your common trigger key could call up a palette with:
- OO Open in Orion
- OB Open in Brave Browser
- OF Open in Firefox (masochists only)
- TC Title Case convert selected text
Now, that is fine for macros beginning with "O", because there will always be a second letter to type, but for "TC", you might find yourself typing a "C" where you do not want it, because the macro will already have been triggered by the "T". A workaround there is to add an empty, dummy macro that also begins with "T".
- TX
You will then always need to type a character after "T".
I do actually use a function key for this method, but it's not on the top row of a conventional keyboard (yes, I am referring to programmable keyboards yet again, and it's... No, I'll spare you the details!). The underlying point is, of course, that the key needs to be readily accessible and not a long stretch away for the finger.
This did not seem to work for me under MacOS 14.7 Sonoma, but don't assume my result is typical. 
I hope there are some useful ideas there.