We're talking about an edge-case scenario then, the interaction of a DLL with mIRC. This is really something that nHTMLn.dll should handle (I'm aware of, but not familiar with this dll), but I'm guessing modifying it could be difficult.
An easy workaround would be: /sendkeys {TAB} (using the standard sendkeys alias floating around the forums).
The real solution might be slightly more complicated, but this is a good starting point.
/editbox -af does what it's expected to do under normal usage conditions of mIRC. Since you agree /window -a $active is not a bug, /editbox -af can't be one either (they do the same thing with the extra action of forcing focus on the editbox in the latter command). Your issue can't occur unless the UI was fundamentally changed. If a DLL heavily modifies the UI to the point where commands no longer behave sanely, it's the DLLs responsibility to mitigate that, not mIRC's.
