I had a custom script to scroll DOpus horizontally that worked great:
you could control the speed
on a change of direction it ~immediately changed direction disregarding the "buffer" of other scroll events
With the native scroll the fact that it's slow is already reported Horizontal Scroll Is Slow, so this report is for the second bug.
This is especially pronounced with some "free moving wheels" where the wheel movement can be very fast and send a lot of scroll events. Yet, when you change the wheel direction, all those many events should be discarded and the direction of software scroll should change right away rather
Interestingly enough, the good old vertical scroll doesn't suffer from either of these issues
The issue isn't that it doesn't respond, but how it responds. The app basically waits until all buffered scroll events have been reflected in the UI scrolling instead of dropping them and changing direction.
I've seen the same bug in other apps, for example, the default WinExplorer is so bad that it has this bug even with the regular vertical scrolling!
But then other apps work fine with both vertical and horizontal (shift+wheel) scrolling
Pretty much all Windows apps will do that (including File Explorer, as you say) if painting is slower than the scroll events being sent to the apps.
Normally you would not be able to generate horizontal scroll events faster than the window can be repainted. (And the mouse drivers should really coalesce messages generated by free-spinning wheels to reduce the number of requests from that kind of wheel, although I expect some don't.)
If you're using background images, grid lines, or lots of column color blending in the file display, that can have an impact (large in some cases/configurations) on how fast the window can draw, and turning them off may improve things.
That's not true, few apps are broken like this, that's why Explorer is notable, but I've only given it as an example just because you've specifically asked for other broken examples, it wasn't a representative of some general state...
Even MS apps aren't broken: Notepad, Word, or Excel (another app with a lot of rows) scroll just fine and immediately change scrolling direction on a change in wheel direction (so do many other apps, incl Chrome, though the ancient HTML .chm help reader app is also broke).
Normally you would not be able to generate horizontal scroll events faster than the window can be repainted
Why? You have extremely slow scrolling speed, so it's trivial to generate enough events even without the free wheel
But also, I don't see why that's very important: just drop the yet-to-be-painted mouse events in the queue and change direction?
Notepad does, it's not the upgraded version, but the old one
We don't in general.
You do, that's what the other linked issue is about, your horizontal scroll is very slow (small distance per tick compared to the vertical one)
And again, with a custom AHK script I can both increase the distance and avoid the lingering buffer processing, somehow the direction switch is immediate as well, so it's not about layout complexity (but also I don't have any images, many columns, etc.)
Also note that the same layout works fine with vertical scrolling in Dopus, it reverts direction right away