Thanks @CJK,
I appreciate that detailed explanation, particularly the emphasis on
That concept helped me make a fundamental design decision.
All those variables are needed if I want to do the non-notification AppleScript actions here instead of as separate calls AppleScript from KBM. That makes this code unnecessarily complicated and therefor error-prone. What it would take to set up defaults and error conditions inside this notify:
handler is way too much.
The other route, without all the variables, is to simply have this code be a trigger and nothing else. It tells KBM that an event has happened and KBM takes it from there. Simple, modular, easier to maintain, and with serious workflow benefits.
I complained about the AS development workflow of having to save it as an app and then close the Script Editor so that SE would not also run when I ran the App. Many additional steps every time I altered anything at all in the code. OTOH, if all this code does is trigger KBM, then it can tootle along in the background and I can do all the other querying, processing, and notification steps in KBM, which means that if I change the data displayed in a notification banner, that's it, it will happen that way on the next Space Change, via KBM.
Actually switching back to the previous space
So taking this back all the way to the OP question (the Forum UI keeps asking me, "Has your question been answered?"), the trigger we have now will allow KBM to keep track of all Space Changes, so it can always know what the previous Desktop Space was, by number or name, or whatever. The second part of the question is using that identification to actually do the switch to the new Space. @_jims's Desktop Spaces macros can do that for 16 or fewer spaces.
For me and my purposes, I want to be able to access Desktop 17 through Desktop 21, and there's no hotkeys definable for those. KBM can't simply define a key when there isn't an underlying OS operation, and System Preferences > Keyboard > Shortcuts > Mission Control
only has operations defined for the first 16 Spaces.
I've done lots of research on Stack Overflow and Ask Different, finding threads about Desktop Spaces going back to Exposé. It seems that anyone who gets into this issue agrees that Apple is not supporting it well, support has gotten worse not better, and if it had better support it would be a powerful tool. People want support for more than 16 desktops, they want to be able to name desktops, and they want names to follow the Desktop if you change the order in Mission Control.
All of those were addressed by the CurrentKey app, which works for me, personally, now, but which is no longer available. So I'm still wanting to be able to do those things without relying on CurrentKey.
So far, on Stack Overflow and Ask Different, the state of the art is variations of the method that CurrentKey uses: place an app window on every desktop and use changes of window focus to get the OS to change Desktop Spaces. CK has its own simple app that simply creates windows and hides the windows behind the toolbar. Other SO and AD systems use things like Stickies (but Stickies itself has the downside that on a reboot, all the Sticky windows are collected on Desktop 1).
There had also been some systems that actually did rename the desktops in Mission Control, using code injection, but SIP prevents that, and I'm not willing to turn off SIP just for that.
So my next design decision is whether the Space-identifying app is hidden (like CurrentKey) or is visible, like Stickies (where people often use 72 or 120pt type so that the name of the desktop is visible in Mission Control). Many of my desktops have status or to-do lists on them, so I've also been considering letting the To-Do list be the identifying app.