1. Under what circumstance is it appropriate for the windows to be moving around this way within mIRC?
Under the circumstance of scrolling, it is appropriate for windows to be scrolled. The question should
be "under what circumstance is it appropriate for the trackpad to scroll the MDI client window", and the answer, as Khaled said, is when the MDI client has focus, not when a child does. It seems that your trackpad is incorrectly
sending WM_SCROLL events.. it's not mIRC's job to clean up after your crappy driver's mess, since it would break the ability to actually scroll the MDI client when you *really wanted to*.
2. Under what circumstance is it appropriate for mIRC to be handling window messages incorrectly, or not at all?
None. mIRC handles window messages correctly
(you might want to repeat that to yourself a few times before you outright ignore this fact in your reply).
1. Does mIRC overrides default behaviour here: the MDI window has that feature by design but mIRC does not use it? If so, then why isn't it doing a complete job of overriding the default behaviour?
mIRC doesn't override MDI client window scrolling behaviour at all, so there's nothing incomplete about what it's doing. It seems you're misinterpreting what Khaled is saying. His use of "mIRC" in "There are no circumstances under which mIRC will scroll" refers to mIRC's codebase. There is no code in mIRC which will scroll the MDI client window. However, the MDI client in mIRC *can* be scrolled by sending WM_SCROLL messages to the wrong window. This is Windows behaviour. As Khaled succinctly stated, the question you should be asking is "why is my driver sending WM_SCROLL to my MDI client window?"-- and mIRC's forums cannot answer that.
2. Are there any other areas where mIRC should (and does) override a controls' default behaviour? If so, why?
Sure. Scrolling is not one of them though, since, if done correctly, there are perfectly valid reasons to allow the MDI client to be scrolled.