Great stuff (Dan is a marvel), and as the saying goes, the best camera is the one you have on hand.
Still, I still like my idea better as it's cursor driven, takes fewer actions, and I avoid typing best I can (ty Keyboard Maestro). I'll not be holding my breath waiting for it to magically appear. 
As always, thank you for your time and attention. They are always a gift.
In contrast, there are many people who use Keyboard Maestro to avoid having to take their hands away from the keyboard to use the much slower mouse.
Personally, for things that I use dozens or even hundreds of times a day, I prefer hotkeys because the steps of moving my hand, reaching for the mouse, moving the mouse, targeting the spot on the screen, sometimes waiting for a menu to open and targeting another spot on the screen, sometimes scrolling the menu, and then returning my hand and finding the home keys on the keyboard, all seem to take too long. A hotkey lets me act almost as soon as I think.
But for things that I use rarely, I often prefer a menu and a mouse so that I don't have to remember keystrokes and hotkeys for things I use less than once a day.
I need to dedicate a full day to this topic. I haven't replied because I have so many new thoughts on the matter. Much interesting input here already.
I'd like to gently field an idea: I'm thinking of holding a contest here with a small cash prize for the User-geniuses of the KM Forum to come up with a best/easiest/most elegant solution for building a macOS-style nested GUI/folder hierarchy to house the Macro Groups.
Would anyone be onboard for this challenge? You'd need a working knowledge of the development platform of KM. Perhaps. Or perhaps the most clever solution would be a universal idea, independent of specific platform. We'd need a volunteer to peer review the solutions, someone who is fluent in the development platform.
I've consistently heard that it will take a massive effort to create this macOS-style GUI, that it will add mountains of upkeep time. @ccstone even said it would cost a cool million dollars! With so many AppStore offerings running these kinds of folder structures, I do wonder if it isn't simple SDK stuff.
This isn't the call for submissions/the contest. This is a gentle fielding whether an idea of a contest is interesting to the Forum users. Obviously, @peternlewis fully onboard with the idea would be important.
Just because we play the game of finding a best-fit solution, doesn't mean it need be implemented. Could just be a way of gauging true interest. Who knows, perhaps an element of fun might enter the topic.
Nope. I never said such a thing – but I did say:
Sounds like you already have a solution: which SDK is that?
"Simple SDK stuff" is often anything but, especially when you are trying to shoehorn in an existing data structure that wasn't designed to be viewed in such a way.
This always starts with a statement of requirements. This needn't be realistic, but it should be comprehensive. So what would you want this solution to do, and what would you want to do via it?
After all, it's easy to mimic a folder hierarchy if all you want to do is easily find things -- just use a hierarchical naming scheme analogous to Unix or old-style Mac paths. Reverse-naming, as with plists, is a pain to manage in the Search field but it is nice to have the macro's name leftmost in the lists, so mix the two formats:
My Address - Nige_S:Text Expansions:Pages:Boilerplate
...would be like having a "My Address" macro in a "Boilerplate" folder in a "Pages" folder in a "Text Expansions" folder in the "Nige_S" folder.
To "open" my Text Expansions "folder" I'd select the "All Macros" Group and type n:"Nige_S:Text Expansions" -- and I could, of course, write macros to help fill in the search!
OK, donation towards perspective change. (Sounds like a tax audit nightmare.)
Keyboard Maestro runs on macOS. macOS used to have a development SDK. seems like Xcode is still a thing: Apple Developer Documentation
I know next to nothing about those nuts and bolts, only that the idea is that there are GUI elements in-built to make crafting applications easier. No? When I see multiple applications all using the same macOS-like GUI elements, my assumption is that those come from a provided codebase. Again, I know nothing but do realize that there are myriad complexities. The idea of a contest was to address those.
I'm going to forget about the idea of a folder tree for Macro Groups. Peter has again stated that he prefers to spend development time on other aspects. I have appreciated the interesting workarounds provided here and will give some of them a whirl. Thanks for the discussion on it.
Do you want to do anything besides organise macros into tidy groups? I'm thinking that many things might be achievable with Smart Groups, perhaps mixed with some scripting and name-tagging. Kind of the way that Google Mail doesn't actually have folders, it just looks like it has.
Note that you would only be changing the name. My example was explicit and the name additions verbose, but you could have your own system of much shorter "tags" you could then use as filters (back to Gmail...). Again, a lot of the initial setup could be automated to an extent.
Remember that a KM Group isn't just organisational -- it's also functional. Would you disable those functions as soon as it had a sub-Group, would the sub-Group not have those options (so it's not actually a Group any more), something else?
I do like the idea of an organisational hierarchy as you describe -- but I hope you can see that it isn't as simple as it might appear!
Keep in mind that Keyboard Maestro was never designed to have many hundreds of macro groups and that people who have that many represent a microscopic edge-case in the Keyboard Maestro continuum.
I have 196 groups myself and need to upgrade my hardware to keep up with them.
I certainly don't dispute that, but it's not Peter's problem to fix.
Have you explored running macros as XML from AppleScript? That certainly has limitations, but you can organize them in the Finder at any nesting level and call them at will without worrying about whether a macro-group is active or not.
A trifle.
Compiled scripts run significantly faster than text-scripts.
You should experiment a bit.
Once you know how to extract the correct XML from a macro it's not difficult to create an AppleScript out of one, and I think this could easily be automated.
You could have thousands of AppleScript'ified macros in organized folders without bogging down the KM plist file very much.
With this kind of organization you could use all kinds of conditionals to decide which script to run per palette button – ETCETERA...
Open your mind and play around a little with the possibilities – you might improve your world – and it's worth finding out.
Too many to alpha-sort got it. My first thought is to find a way not to need so many groups, and I don't know what you're doing, so can't think about it.
Last thought, have you played with exporting macros as 'Trigger Files'? They can be sorted into Finder folders and organized within the Finder's filing structure using folder hierarchies and/or tags.
I only recently discovered "Trigger Files", and I think they're awesome. Not that I'm using a lot of them, but the concept is pretty cool.
I have a few in my Finder Window Toolbar for sorting by name or date modified and another that calls up the file nav window for the currently selected file. Pretty handy! It'd be nice if all app window toolbars were so accommodating.
Came here to say that looking at the comments on this topic, it doesn't seem like a "minority", Peter. I don't know how you would know that without asking all users to vote for a feature. This seems like a very obvious feature that probably most users would use.
There's a reason why we have Finder with multiple folders with sub folders, with sub sub folders, etc. It's part of our daily workflow.
I'm one of those people who would love that KM would allow this.
Regarding what some people mentioned about the issue of importing other people's macros, I see the folders and sub folders feature more like a local thing. So even if my macro is inside a sub sub sub folder, that macro itself is always referring to the parent folder, aka Macros Group, so this wouldn't affect other users who import that macro.
It's just a visual thing, nothing else.
Just my 2 cents...
Unfortunately what I get from this topic (and some others) is that sometimes some decisions are not based on users, but on the developer's assumptions of what the users might use or not use. That to me is not the best approach, but, who am I, right?
It amazes me sometimes that we as users have requests that seems very basic in terms of what we expect an app to be (this doesn't only apply to KM, of course), but sometimes those requests are ignored. The reason why that happens, is beyond me.
In this particular case, no one is asking KM to make a pizza (which would be equally awesome!). We are asking for something that most apps have (and for a GOOD reason).
Todoist has project, sub projects, etc
Notes app on Mac has folders, sub folders, etc.
Hazel can group folders/paths into folders/groups
Photoshop can group layers into folders/groups.
I can be here all day.
So when we are told that having folders would only satisfy a "minority", I don't really know where that idea comes from. And to be honest, it makes me "sad" that this approach is visible in other areas of the app, which I already publicly mentioned, but I keep getting the same reply: "This is how it works, because XYZ reason".
Just because something works "this" way, doesn't mean it can't be improved, otherwise we would never evolve.
Don't get me wrong, I love KM and this community. This app has saved me so much time and work.
I'm just expressing my "disappointment" for feeling that sometimes certain things that clearly make no sense, are ignored, "just because"...
I understand that super particular requests can't be fulfilled. I get that.
Having the ability to group macros into folders, I am sorry, but it's definitely not that "particular". It's not a hyper priority? I get that. Saying that "I will most likely not implement that", sounds a bit "rude" to me, when it's clearly a beneficial feature.
Again, just my 2 cents...
OK - That's enough. Can an Admin please close this thread? It is NOT productive and it has elevated into unnecessary areas.
Thank you.