Hm, but then the contents of $ibl may still end up being "wrong" (in the sense of the original post here) if mIRC retains its fully case-insensitive ban tracking based on MODE +b/-b changes?
mIRC would not be tracking or storing the contents of mode changes - all it would see is that eg. a new mode +/-b had arrived, so it would change the state of .ibl to $false.
Also, that means that after a ban list has been requested already, half the ban list may still be missing from the $ibl list during a new channel-central-incurred banlist update (ie during the $inmode state) from a script's point of view?
This has always been the case though. That is why $inmode was added, so that scripts would know if it was being looked up.
I think this does have the potential to break some scripts, especially those implementing their own channel central kind of thing.
I am concerned about that, however it seems okay so far... if a script is checking for the .ibl value, it will continue to work as before. If it isn't checking for the .ibl value, then it never had a guarantee that the list was filled anyway.
I don't know, is telling UnrealIRCd to get their shit together not a better option after all?
It sure would be :-)
