Personally I'm dubious about the addition of the hardcoded x/y coords in an event like this. I can only imagine a few very simplistic scenarios where these values would be useful to a script. Most scripts will quickly outgrow hardcoded values and require dynamic hitbox testing-- specifically, any window that supported resizing would not benefit from hardcoded x/y values. I think depending on $inrect inside of a mouse event makes much more sense than providing two extra parameters that most users won't use.
You say that adding the x/y makes it easier, but again, only for your simplified example. By using pseudocode for your example, you make it seem like your checks for "if mouse isin buttonA" is a simple hardcoded check, but in most cases it is not. You will more often than not see something like
if ($inrect($mouse.x,$mouse.y,$calc($window(@win).w - 200), 10, $calc($window(@win).w - 20), 20)) .....
As another example, if I were using a @window to draw the equivalent of a channel window (with buffer, nicklist and editbox areas), hardcoding x/y would not be possible. And this is a very simple custom window drawing exercise. The other examples I can think of are games, where hitbox testing are very much dependent on game state, not hardcoded values.
So I would suggest dropping the x/y params. But then you're just left with:
As opposed to:
Which seems like a shallow aesthetic change. Yes, I agree that, syntactically speaking, mouse events are inconsistent with other events-- but only syntactically. You can view the menu definitions as just another way to write an event. Conceptually, they are the same as other events. The two samples I showed above are completely equivalent. The difference really is just syntax. And I personally don't see aesthetics as a reason in itself to deprecate over a decade of code.
