Ah, I think that makes some sense now, especially given that this delay seems to have been added in KM 11.0.2.
The first instance of the macro locks the semaphore for ~0.3s because it won't unlock until the macro is done running. If that is the only instance that tries to run, then there are no timeouts or notifications. If I try to run the macro again within that ~0.3s time, then the second semaphore gets blocked by the first and times out after 0.01s, leading to a notification.
However, it seems like the blocking I am experiencing is much longer than the ~0.3s expected.
I timed the "Move Window" action in KM 11.0.3 by writing MILLISECONDS() to a text file before and after it runs.
I can then change the delay time using:
defaults write com.stairways.keyboardmaestro.engine WindowSetFrameAnimationTime -float 0.0
With a delay of 0, I get a time of about 11 milliseconds! However, if I set the delay to 0.3, which should be the default,
defaults write com.stairways.keyboardmaestro.engine WindowSetFrameAnimationTime -float 0.3
then I get a time of about 1218 milliseconds.
Just to double check that 0.3s is the default value, I repeated the timing after running
defaults delete com.stairways.keyboardmaestro.engine WindowSetFrameAnimationTime
and got a value of 1217 milliseconds.
So, this delay that has been introduced is significant—over 100×!
Also, while it is nice to have the ability to turn the delay on or off using defaults, I find that approach a bit concerning. Now, macros containing window frame manipulations are no longer transportable between different computers. I might have a macro that works best with my local configuration, but because that configuration is hidden and not attached to the macro, the macro is no longer a self-contained unit. It is a small issue, but I think it would be very nice if .kmmacros files contained information about configuration like this.