You can, but it seems to be going against what a subroutine is actually for -- and it could get interesting when it comes to parameters.
And if you do want to run a parameterless subroutine async, can't you just call it with an "Execute a Macro" action?
Yes. But I do like the Action that calls subroutines with its clear indication of the parameters:
Compared to the Execute Macro Action, where more hoops have to be jumped through to pass the parameters:
Running the subroutine asynchronously would only work if no parameters need to be returned, for example to show a dialog that remains on screen, while the caller Macro continues.
You can still return, you just have to post to a variable rather than use the "Return" action. If you're running a subroutine with a "Return" async, what does it return the value to? (I must stress that I haven't tried this yet!)
But I'm more concerned with parameters -- IIRC these are internally indexed by the Engine (rather than easily available, like trigger values). If you can simply pump in an <array> that one-for-ones with the sub's parameter <array> then my worries disappear...
Aren't you going to lose that visibility as soon as you wrap it all into an AppleScript? Or am I misunderstanding the plan?
Unfortunately yes. Which is why maybe I got a bit too excited too quickly 
A way I have achieved this in the past is to have the Subroutine execute a script and that script can be set to run asynchronously (my goodness that's a fiddly word to type).
Might it be possible to group actions as part of the prepared xml, if multiple actions are selected? That way, it would work for multiple selected actions without them needing to be manually grouped beforehand.
You could drive it with KM actions -- select menu item "Group" of menu etc... and then select menu item "Parent Action" of menu etc.... You might be able to get the number of actions selected from the "Try" or "Disable" menu items of the "Actions" menu -- at least enough to make sure you've more than one action selected so have a need to group.
Or you could include it in the AppleScript, although it'll involve System Events so you'll need to make sure the Editor is frontmost (it probably will be, but just in case...):
tell application "Keyboard Maestro" to activate
tell application "System Events"
tell process "Keyboard Maestro"
click menu item "Group" of menu "Engroup" of menu item "Engroup" of menu "Actions" of menu bar item "Actions" of menu bar 1
click menu item "Parent Action" of menu "Actions" of menu bar item "Actions" of menu bar 1
end tell
end tell
...which will engroup the actions then change the selected item to the group, ready for the previously-posted methods.
That's probably more straightforward than what I had in mind, which was to adjust the initially copied xml to include the necessary grouping bits if they don't already exist.
I'm thinking it's better to have a group from a UX perspective. You lose the multi-action selection when you add the new action, and while you might be able to re-select those actions using the original selection list, what do you do then? Deleting them can make tweaking the async routine difficult (you'll have to edit the XML), keeping them all individual and disabled adds a lot of clutter. And there's always a problem later on knowing which actions were included in the script action...
Putting them into a Group action solves most of those problems, with minimal bloat (unless those actions include lots of images...).
If you do want to engroup as part of the script:
<dict>...</dict>s, one per action<dict><key>Actions</key><array> </array><key>MacroActionType</key><string>Group</string><key>TimeOutAbortsMacro</key><true/></dict>...and you're in the right place to either paste the XML into your AppleScript or to encode it as per your earlier macro.
Ah yes, of course. I hadn't followed that through from a UX perspective. I had given some thought to the idea of a reversion macro, so you wouldn't need to keep the original actions, but that would rely on the user having it and knowing/remembering they can use it.
KM doesn't do this anymore. I can delete single characters with no problems.
I think you will find nothing has changed. If the prompt field has a default value, pressing the delete key when the prompt appears, deletes the whole string (because the whole string is pre-selected). If you do not have a default piece of text and type something in the empty field (or click to deselect the default text), then pressing the delete key will delete one letter at a time.
Well, truly nothing has changed, because it's doing it again. Here is a screencap:
I also tried it without the default name, and it does the same thing. Any ideas how to get it so it will delete one letter at a time in the User Input box? Thanks.
The fact that this is changing is interesting. My only theory is that you have a macro somewhere that is using the "delete" hotkey to redefine what it means. This could explain why it's intermittent, as your environment may change, resulting in the macro being enabled sometimes and otherwise not enabled.
To disprove my theory, just check all your macro group folders to see if you have any macro that uses the delete key as a hotkey. If so, check what those macros do.
If I'm wrong, you may want to specify which version of macOS and KM you are using.
As @Airy is saying there must be something unique in your system, like another Macro or App causing this as it is not normal. This is what I get when I do what you are doing:
thanks for that - you're right, I found the offending macro and deactivated it -- problem solved. 