I noticed that after a loop, sometimes a bug occurs with the treebar update, I managed to reproduce it with a specific code.
Type this in a status window:
when it's done, wait one second and change the active window, the color of the item in the treebar for that status window is the Event color (options > display), instead of black.

Also, the -g[N] switch for /window supports N = 3, (set the Event color), but it's not documented in the help file

How is this a bug? You are echoing to a non-active window so it gets marked with the event color. Sounds like expected behavior to me.

You must wait the end of the loop + ~1 second before changing the active window, so the text is echoed to the active window

Ah, I see what you mean now. My guess is this is because Windows treats the application as "not responding" after 5 seconds. When it enters the "not responding" state, Windows is probably no longer indicating to mIRC that the program is active, thus the color change. Loops shorter than 5 seconds don't cause this to happen.

Well, it's probably something related but I still think mIRC is doing something wrong: it knows the status window is the active window and it shouldn't color anything in that case.

If it IS a Windows thing, then no... mIRC doesn't know the status of the window if Windows doesn't mark it active when it's "Not Responding." I don't know if it's a Windows issue or not, but it definitely sounds right to me. Any time you hang a program, there is a chance of things being done differently while it is hanging. It may be better to find a way around a loop that hangs mIRC. There are usually options to avoid that, depending on what you're doing.

Whether or not this is something that mIRC can "fix," I'm not sure. How will mIRC know the difference if Windows says it's not active while hanging or if Windows says it's not active because you have another window open on top? In one case, you want to mark the events and in the other case, you don't. I'm not sure that you can have both.