but as far as an user can see, filter is just an alias
Right, it is an alias. A callback is simply an alias called back from the callee. In other words:
(1) your_script ---(argument: callback_alias)--> mIRC_function
(2) callback_alias <---------------------------- mIRC_function
Any scenario where the above interaction diagram occurs is what's known as a "callback" alias.
The issue here is that mIRC makes no guarantee, neither in docs nor logically, that the callback is called "immediately", or "in the same context". There's nothing to imply that it should be called in that fashion, either, and in fact, forcing this might limit the ability of the mIRC function to do something important (like threading, etc.), which is likely why it's currently not executing in this fashion.
Another way to explain this is to say that you are passing mIRC the name of an alias, sure. But you're not telling mIRC when or how to call this function. That's why I said earlier that you should never expect an alias to be called in the same call chain unless you explicitly /call it yourself. I don't see why mIRC needs to officially guarantee that the alias is called back from the same call chain-- that is an implementation detail that should be left up to mIRC itself. If you need to pass some kind of state along, you should find a more appropriate way to do it-- frankly I don't even see why $v1 should exist outside local scope of an alias in the first place ($v1 should behave like /var IMO), but that's just a quirk of mIRC's language implementation, and I'd say you're just getting lucky in those other cases (again, my opinion here).
Note that mIRC has callbacks in other scenarios, like $comcall, my guess is you'd have the same expectation there (especially since it is entirely async.).
