If there is a good reason for this to be done internally, the simple scripters we are can only see this as a very annoying behavior.
You can't just tell him he doesn't need -n, it might be true, but he might also have given a simple version of what he is doing to show the issue, perhaps he has heavy operations following the /signal command and he does want -n, where waiting for the end the script execution is not an option.
In the original report with $wid, $window().wid could be used as an easy workaround but in the case of $mouse, it's not that easy because he does not take a window parameter.
I agree the documentation of $mouse isn't the problem, but nor is -n in /signal, $mouse.win inside an on text event triggering inside #test, completely unrelated to signals, would fail the same ($mouse.win should not be returning #test but the current active window at the time, according to $mouse.win doc): any operation made inside an event which is relying on 'window' will fail.
The undocumented behavior is that mIRC triggers almost all events with the status window set as the active window, a similar analogy is how $1 etc are used in $regsubex to handle the subtext special markers, mIRC steals your $1- for a short period of time, so short it's undocumented!, here mIRC steals your active window before restoring it as well. I think it's not documented to keep things simple, eventually the few scripters puzzled about it will be answered here.
The help file says $mouse is about 'mouse event', so I think that part should be reworded, it works outside the menu { event.. The workaround he needs is $window().prop, passing the window's name $menu in /signal -n
