Your footnote about the differentiation between macOS Keyboard Shortcuts and KB hotkeys set me on the right path, though I am not sure the footnote is exactly right - more on that below.
You are correct that a 4 and a keypad-4 are different, and I had made the appropriate changes in your macro per the instructions and had put keypad-#s in all the appropriate spots. And you are also correct that changing the settings in SysPrefs doesn't SHOW a difference between a # and its keypad-# equivalent. BUT it does differentiate between them. So when I used Keypad-#s in the system shortcuts, it LOOKED JUST LIKE using regular numbers, but when keystroking it, it worked correctly using the keypad-# but not the regular #. I would call that a bug in the user interface, but the ultimate behavior is exactly what is expected, so no biggie. So I do think the numbers ARE differentiated with macOS Keyboard Shortcuts - it is just that there is no visible evidence of it in the settings. As an aside, I was using the keypad-# scheme instead of the one you defined in the macro because some of the "regular" number shortcuts were already taken in my system for conflict palettes and I didn't want to have to change a couple of dozen KM hotkeys. Using the keypad-# scheme let me have consistency without any such conflicts. Unfortunately, the consistent thing was that it didn't work and I came to the forum to figure out why.
I had carefully read the messages in Simulate Keystroke Not Working in Mojave as you had suggested earlier, but was misled by the line in one of Peter's posts about simulated keystrokes only working with letters - I figured "that obviously isn't the case anymore because Jim's macro simulated keystrokes with numbers" and I was not trying to use the special characters that were the focus of that thread. But after reading your footnote I decided to test the Simulate Keystroke action and, lo and behold, it DOES NOT WORK with the numeric keypad, even though it works with "regular" numbers. In short, you nailed it much earlier in this thread, but I was lost in the weeds and didn't appreciate your perspicacity.
In looking at this from scratch this morning with the benefit of the additional clarity I gleaned from your footnote, I said to myself "just for kicks, let's set a Mission Control desktop shortcut to a letter and see what happens".
Being the smart guy you are, you can guess the ending. YOUR MACRO WORKED!!
I am happy that it now works and happier that you taught me something about the keypad that I wouldn't have figured out in a million years - I use the numeric keypad in lots of KM hotkey triggers, and the seemingly subtle difference (albeit with enormous practical consequences) between hotkey triggers and simulated keystrokes would never have occurred to me. My wife is happy because the difference between being able to use your macro and make efficient use of Desktops or not might have been the need to go out and blow $1600 on a second Studio Display. Hopefully with the facile use of Desktops now, I can avoid that.
So, thank you again for sticking with me through what is now post #24 in this thread. I am a big puzzle fan and hate it when they are unsolvable - glad that this one ultimately had a solution.
Is there an easy way to change the ⌃D shortcut for multiple entries at a time? I already use that in multiple applications (terminal sessions, for one, where it's used to send an EOF) and changing it in 43 macro entries is not looking like it's going to be fun…
I'm guessing I could write a macro to edit the macros
If your Move left a space and Move right a space Shortcuts are unchecked (screenshot above), this is encouraging as it indicates that a large portion of the macro logic is performing as expected.
If you haven't done so already, please use ⌃← to move to Desktop 1. From there, use ⌃→ repeatedly to move to Desktop n.
Also, using the Conflict Palette, please test desktop space navigation to all of your Desktops:
Display the palette using ⌃D.
Click on an entry in the [ go to Desktop ] section.
Repeat for all of your Desktops.
If any of this navigation does no work as expected, please let me know.
That arrow movement is expected. The macros move windows by clicking-and-holding the mouse in the upper-left region of a window, navigating to the target desktop space, and then releasing the mouse and returning the arrow to the original location.
For some reason, yet determined, the navigation portion of that sequence is not working as expected.
One question about the conflict palette, how do you trigger any of the move window triggers? I'm used to a conflict palette where each of the macros start with a different letter and I can just start typing to trigger them. But that's not really working in this palette since they all start with "to".
Thanks again for all your help -- I'm a relative beginner with this tool but it's helping me a bunch!
Great @blfarris, glad you found the configuration issue.
First, your Conflict Palette will look different than mine unless you have your Keyboard Maestro Preference set as follows (Keyboard Maestro > Preferences... > Palettes (section) > Conflict Palette Style):
The Conflict Palette macros are named such that all can be launched with one (left column items) or two characters (right column items).
You don't need to wait for the right column items to be displayed. That is, you could run macro 24)to 1 ⌃⌘1 by quickly pressing t1.
Some of the macro names include the hotkey that will directly launch the underlying macros (bypassing the Conflict Palette altogether). Other macro names don't include the hotkey (I choose to exclude some to reduce Conflict Palette clutter.), but all underlying macros do include a hotkey trigger. For example, the following hotkeys will run the macros that:
⌃7 navigate to Desktop 7
⌃⇧⌘1 move the active window to Desktop 11
⌃↩︎ navigate to Previous Desktop
⌃⌘0 move an Application Window to the Current Desktop