This is basically the same issue as typically seen in reverse when people try to capture a key (Trigger hot key Control-R), and then conditionally type the key to perform it’s actions (Type a Keystroke: Control-R).
It is undefined what will happen if you simulate a keystroke that is a hot key trigger.
So the behaviour you get will be either:
- triggering the macro (in this case resulting in the conflict palette as hoped) or
- typing the keystroke (in which case whatever Control-R does would happen (which on the Mac is normally nothing)).
and there is no way of predicting which you will get.
Keyboard Maestro tries to get the latter behaviour (which is what you are actually seeing) but because of the keyboard event queue it is impossible to guarantee (which is why people often see the other behaviour, especially in Sierra where something subtle has changed in the timing that causes the former behaviour to be far more prevalent).
I understand the desire to trigger the conflict palette from a macro (its actually on the todo list), but currently there is no way to do it directly.
Probably if you use an AppleScript to simulate the keystroke, that would reliably work to trigger the macro (since Keyboard Maestro would then not be trying to get the latter behaviour).
And probably Keyboard Maestro should just give in and accept the former behaviour as the definitive behaviour because that at least would be reliably consistent. But in generally when you’re simulating a keystroke you do not actually intend to trigger a macro, so the latter behaviour is preferred.