For what purpose are you using #InputLevel?
I have another running script,
DirMenu, which captures middle mouse button clicks. If I don't have my mouse with me, I want to be able to use the right and left buttons on my touchpad to simulate the middle mouse button.
Without
#InputLevel 1, DirMenu won't see my simulated mouse clicks.
SendPlay bypasses the keyboard hook, and therefore never triggers hotkeys regardless of #InputLevel or SendLevel.
That is why I used
SendMode Input for the key combination and overrode it with
SendPlay {Click Right} for the right click.
As the prefix key in a custom combination can be used in many hotkeys, under many different (#if) conditions, with many different input levels, it isn't feasible for #InputLevel to apply to the prefix key. Instead, the prefix key x in x & y:: acts as though it is at #InputLevel 0. If the key is only used in custom combinations, any simulated event at SendLevel 1 or higher will be blocked as if it was a physical event.
You seem to be saying that middle clicks simulated by the script above will not be captured by DirMenu because it uses
#InputLevel 1. I know that is not the case because I am using the script above right now to fire the hotkey defined in DirMenu. If I change the line to
#InputLevel 0, the hotkey is no longer activated.
The real problem is that when a hotkey x:: is also present with #InputLevel 1, key-up events at SendLevel 1 or lower are "ignored" by the hotkey (which fires only on key-up) - but are also ignored by the prefix key, so they pass through to the active window. It seems that if you send a right click-up event to the system tray, it will pass the message along to whichever icon last had a click-down event, rather than the icon under the cursor.
Luckily
SendPlay {Click Right} seems to avoid this problem, probably because
#InputLevel is being ignored.