I wouldn't call this a bug. It's not the only way to skip the initialization warning, there are plenty of others. The initialization warning should not be your only defense in using scripts. Users have to execute some kind of discretion about what scripts they do or don't load, either by looking at the scripts beforehand if they're capable, or only downloading from trustable sources (script sites with mandatory review processes, etc) if they aren't.
As far as your specific code goes, there's no way to tell whether your grouped on start event is legitimate or not-- the syntax you posted above *does* have legitimate uses and therefore it itself
cannot inherently be a bug. For instance, a scripter may decide to use groups rather than if statements to check for "first start" status, saving a variable:
#first_start off
on *:start:do_normal_initialization
#first_start end
on *:start: {
echo -a This is the first time starting mIRC with this script loaded, blah blah blah.
.enable first_start
do_first_time_initialization
}
Of course, they could have reversed the group (start with on state, disable group) which would trigger the initialization warning, but there's no reason to force such a style on a programmer, when a user could just do:
on *:APPACTIVE:do_something
And pretty much guarantee that it will execute at some point in time (even though it's technically not on *initialization*). There are many other events a scripter could hook into that are essentially guaranteed to trigger, meaning initialization warning or not, the check is bypassable.
We could go back and forth forever on all the ways to get around mIRC's sanity checks, like disallowing recursion calls or calling modal dialogs from events-- the lesson here is that there is really no way to truly police a script when you give it full execution control at *any* point in time.
All that said though-- bug or not, mIRC should check for all on start events in a script and not just stop at the first.