Nope, you are forgetting to acknowledge the sentance before the one you quote.

As noted, they are queued. As we know, eggdrop queue support flood protection. This is where is the reason behind modes not being sent. It should probably read "sent as soon as possible" though.

They are not faulse details, more incomplete.

Most people forget that one function of a program, can effect another. In this case, messages in the queue before pushmode is called (the mode queue doesn't just help mode changes), can direct effect how and when the pushmode change will take place.

I hate being right, as much as I love it. However, it's my and my mighty ways, that requires me to ram home messages .

Quite correct, pushmode is not puthelp.

These are two seperate queues, but queue nether the less. The server queue just has higher priority over the help queue.

After a good search of the source code, it's pretty complex. However, the code shows that deq_msg is called, by queue_server, to send important messages in the MODE queue.

On top, it's also called once per second.

Within the deq_msg function, there is code, that will limit the amount of items sent.

The conditions on sending informatiopn from the mode queue, are as follows

1: There must be content in the mode queue.
2: The values of burst must not be above 4.
3: The alapsed time since the last message was sent, must not be below the MAXPENALITY value.

So, if the burst value has been reached, just before some1 joins, the mode can't be sent once the proc has been complete.

The mode will have to wait, until either the "once per second" clear queue has reached the modes position in the queue.

It is quite true, that a equivilant call to flushmodes is called after the proc, but again, the queue needs to be empty enough, for the mode in question to be sent.;

.tcl proc mytest {} {pushmode #chan v nick}; mytest; pushmode #chan +m

Not all modes will be flushed from the queue on return from a proc.

It all depends how full the queue is before the proc is enetered.

Remember, items in the queue are delayed, to prevent the bot from flooding off. If, as you are saying, they are all sent, before another proc is called, then the bot would rather likely lagg even more, during high queue usage.

Not allways true.

During high queue load periods, modes will be stacked, which is beneficial.

However, this again, is simply a performance issue.

why always a * bind? isnt a modular check not faster than a tcl if? by the way this way its only one if... i know, it doesnt matter at all, but teoretically it saves CPU time . and i would recommed using pushmode to make the bot aviable to put multible modes into one line.
Code:
bind join - "#wwwarez \[WWW\]*" warezjoinvoice

proc warezjoinvoice {nick host hand chan} {
pushmode $chan +v $nick
}


btw. tcl-commds.doc is a nice thing to read... not to say RTFM