This may be related to the same root cause as an older issue: 0000522 / r4043 .

Edited: Originally referenced the wrong issue.

Could you please test with r8736 (or later) and set the advanced setting [Pattern Editor]AlwaysDrawWholePatternOnScrollSlow to 1? Note that this will slow down pattern display considerably. Are you still able to reproduce the display artefacts that way?

You can get current test builds at https://builds.openmpt.org/ .

Still setting up my compile environment, and auto build is still on r8733 so I will have to get back to you on that.

Automated builds will always turn up eventually after some time. They are available now.

Hm, sounds like an overzealous optimization in some graphics driver trying to "optimize" GDI's scrolling API.

Problem appears resolved with r8736 and with the advanced setting.

I can't believe I failed to mention I am running my copy of 32 bit win XP sp3 in virtualbox on a 64-bit archlinux. Could have been useful to note...

You mentioned Windows XP as OS version, and thus it was evident that it might be driver related (as in Windows XP, this stuff is handled by each individual driver (in contrast to how things work since Vista)).
Anyway, what OpenMPT is doing here is frankly stupid and, in the long run, should get fixed (by using an additional backbuffer and reblitting from that). What OpenMPT is doing is also painfully slow when using multiple AMD GPU cards and running OpenMPT on a display on the secondary card. In fact, I should re-test in that setup to find out if the redraw-everything work-around is actually faster there.

Until this gets fixed properly in OpenMPT, you can use that setting (as mentioned, this can be measurably slower).
I'll backport that setting to 1.26, so the next stable release will also have it.

Documented at https://wiki.openmpt.org/Manual:_Hidden_Settings#.5BPattern_Editor.5D .
Committed as r8737 in 1.26 (1.26 test builds for Windows XP will appear at https://builds.openmpt.org/builds/auto/openmpt-win32old/ (different location compared to 1.27 test builds)).

The same issue occurs on my old machine running Windows XP Professional SP3 32bit natively, so i'd safely rule out any influence of Virtualbox.

That's not correct, since VirtualBox provides its own graphics driver. It's just true that VirtualBox is not the only wait to trigger this issue.

I'm still almost 100% confident that the root cause is actually OpenMPT intermixing synchronous (ScrollWindow) and asynchronous (OnPaint) window drawing here. That cannot possibly interact sensibly with something like Smooth Scrolling (which I'd imagine basically does similar things, but on the driver side). I'd imagine display drivers (or GDI) going through quite some hassle to even handle that at all.
I have nothing factual to back up the theory, but it appears highly likely to me.