There is no certainly no bug in there; it's a well understood behavior that the code associated with the menu item only gets evaluated when you click on that item. Because of that, you can think of your code as being placed in virtual aliases that get invoked.
The reason it's not working are obvious now, $v1 works outside a scope but it's not working if the call chain is broken (filter breaking the call chain is another topic)
By 'call chain' I assume we mean mIRC is executing the code from it internally from the same root function that executed the original code that created $v1. While that's true in general, it's not really true for /filter since the call chain is not broken. Note that in the menu scenario, it does happen.
It's not something difficult to add,...
No need to quote the rest of the statement however in the case of the menu it's actually not possible to implement it in a sane way, that would require keeping all kind of strange states. Imagine the following code:
menu * {
$iif(1,1):echo -a $v1
$iif(2,2):echo -a $v1
$iif(3,3):echo -a $v1
}If I click 1, will echo print 1 as well? What happens when I click 2? The most logical thing to do is what mIRC currently does - start from blank and execute the code associated with that item. To make it print 1/2/3 for the three menu items respectability requires a hell lot of work with little to no gain and mIRC will now have to keep individual states for each menu item code segment. You have to remember that the code in the item's name gets evaluated first. I.E. $iif(1,1) then $iif(2,2) then $iif(3,3) way before code associated with a specific item gets executed - if it even gets executed.
