Thanks. I would have assumed the Windows clipboard queued rather than blocked calls. And I found the culprit: an open RealVNC Viewer 4.1.3 window on the same machine as mIRC. It had been open to a headless machine for days. The viewer was evidently sensing mIRC's clipboard modifications and attempting to copy each one into its program space. Once the viewer was closed, I could hold F3 indefinitely in mIRC with no problems.
Since this issue can be caused by any number of programs (a la the link from Riamus2), perhaps two things could be done:
Native &binvar support for /clipboard. This would allow (even large) multi-line clipboard payloads to be constructed in advance, so that /clipboard need be executed only once, keeping mIRC "out of the way" of other applications which sense and then immediately read every single clipboard change.
And rather than failing immediately when blocked, let /clipboard and $cb wait for up to 300 miliseconds for a green light from Windows to read/write to the clipboard. This would help conventional uses of /clipboard, like solitary instances of "/clipboard test" or "$cb(0)" which coincide with another application's clipboard access. The delay would even help in cases of "while (whatever) { <build &binvar> } /clipboard &binvar", assuming something repeatedly and rapidly executed the alias housing that code, causing multiple rapid /clipboard and $cb calls after all.
Since most applications which sense and read clipboard changes would, by definition, only be triggered following the use of /clipboard, $cb()'s delay would rarely if ever cause any script slowdowns. For potential speed issues caused by giving /clipboard a delay, on the other hand, mIRC's help could simply point out "/clipboard &multiLineBinvar" as preferable to rapid and repeated /clipboard execution.
