Good catch. And a reminder to us all about not making assumptions when troubleshooting and to start from scratch every time.
It won't. You aren't running a macro to do this, so no trigger recorded. You aren't killing and restarting the Engine, so no record of that. You are forcing a reload of the plist, assuming you are enabling/disabling via AS, which is what's cancelling the prompt -- but a reload isn't recorded in the Engine log.
I suspect that just a timing issue -- a big plist will take longer to unload/reload, and you're triggering the prompt before that's finished. Delete 90% of your macros and see what happens
Ok, so when I make changes to my macros, including enabling and disabling them, it has to update the plist? And the time for it to update and reload, is triggering this?
It makes sense.
When you guys mentioned that something could be triggering KM and I noticed the 15-ish cycle (even though sometimes it was just 4 seconds), the script came to mind, but I wasn't thinking about what it was actually doing until I opened it and saw that it was changing the state of the macros, regardless.
For example, if macro A was enabled and B was disabled, as they should if all volumes are unmounted, I was still running the script to enable A and disable B, even though that was their state. Made no sense. Now, even though I have that first script to check if any macro is running, the logic itself no longer "touches" KM if everything is enabled/disabled as expected. It only changes the macros' state if necessary.
So in the end, not only did we fix the issue, but it forced me to improve the script.
Again, thank you for taking the time to test it, even on a different macOS
Wouldn't another possible way forward be to create a second user account on the same Mac, install KM on that account, load some test macros, and then test with a clean, minimal plist file? If so, I might use that approach myself.
I'm not having a pop! I do this all the time -- "Oh, it's obviously not that because...", only to find out it was that after all and I'd have saved a lot of time if I hadn't assumed.
Hopefully someone here can learn from my (many!) mistakes...
Hence the wink.
No need to install KM -- your newly-created user account will start a 30-day trial as soon as you open the already-installed KM app.
I can't say it for sure, but maybe those issues were related to that plist file you mentioned.
I need to work on it for a while and see how it goes. Maybe sometimes when I experienced that issue, I was working with KM and making changes would cause it to close right away, because of the plist loading. Let's see...
I've learned that a long time ago, in the studio while recording. That's why these days I tend to believe that everything can be the issue, even the most ridiculous thing. Of course, it has to make sense, and today it wasn't, for example when you were mentioning that other macros could be causing it, when I knew there were none running. That's why it was so confusing.
And I think the worse thing is when there's something "invisible" happening and you can't even pin point it. If it wasn't for you mentioning it, I wouldn't never think of the LaunchAgent.
Since I am always Activating/Deactivating or Enabling/Disabling Macros and Macro Groups in my Automations based on what is really needed during my work to make sure that I always have only the Macros I need at that exact time, this information is so damn helpful.
I wonder if there is maybe a chance to get a new Boolean verb in the dictionary that will allow us to check if the KM Engine is currently reloading and let us pause the running Macro until the result is false ?! I thought of reloading - it’s maybe even a great help when used by other tools like LaunchAgents or other Applications using Scripts. Would you consider this as a Feature Request ?!
As @Airy observes, the reload is synchronous, so macros will not run during a reload. Macros are essentially paused, although the reload is essentially instantaneous unless you have a very large number of macros.
Thank You 
to Australia 