Seems like I've found out what causes the different mousewheel behaviour between various controls... This will be unified in the next release.

Revision 1365 should improve this; All spin boxes that I could find should accept mouse wheel scrolling now.

Excellent! One step closer to complete mouse-driven composition! The mousewheel does indeed work on all spinner text fields in every tab, and (almost) all drop down comboboxes when they have focus of course.
(If you're keeping track, the Instrument field on the Patterns Page and the Zoom dropdown stop moving after the first new list item. I also noticed this is true if the "little" sliders -- like the Res value in the Instruments page -- are mousewheeled when they gain focus.)

Furthermore, any slider element (like the Global Volume slider) if it has focus will move according to the mousewheel. If you mousewheel the entry in the spinner text box instead, the slider will also instantly update.

Anomaly, may need to be changed: when mousewheeling to an unused plugin slot in the Instruments page, the Autoselect Plugin feature kicks in. May want to opt out with mousewheel selection or filter the input if possible to only activate when empty slot is singularly chosen by a mouseclick.

Mousewheeling in dialogs:
Options dialog: works very well except for a couple of places. Mousewheeling the Category dropdown in the Keyboard tab indeed scrolls thru the list; then when tabbing into the Function list below it, the mousewheel will scroll the list, but won't move the highlight from the selected entry. Perhaps the mousewheel should instead scroll the selection thru the list of functions to assign hotkeys rather than scroll the view position. The same for the Miscellaneous Options list in the General tab.
I could make the same complaint about the Plugin Selection dialog (mousewheeling only scrolls the view not the selection), but here i don't know if it'll be helpful to modify the mousewheel behavior.
Mousewheeling in the Tree only moves the scroll view, but i don't think we need to scroll the selection of any element here, but OTOH i don't normally use this feature.]

While i don't really like the Transpose contextual menu compromise (i still think +/-4 and +/-7 are common enough to warrant their entry into the list), at least the Transpose dialog uses the mousewheel to scroll quickly thru the values to get what i need nearly as quickly as possible.

With this new capability, perhaps we can have a preference to opt out of spin arrows (those elements are simply not drawn).

<blockquote>(If you're keeping track, the Instrument field on the Patterns Page and the Zoom dropdown stop moving after the first new list item. I also noticed this is true if the "little" sliders -- like the Res value in the Instruments page -- are mousewheeled when they gain focus.)</blockquote>

While there is definitely room for improvements, this is not related to the original issue.

<blockquote>Anomaly, may need to be changed: when mousewheeling to an unused plugin slot in the Instruments page, the Autoselect Plugin feature kicks in. May want to opt out with mousewheel selection or filter the input if possible to only activate when empty slot is singularly chosen by a mouseclick.</blockquote>

Cannot be fixed (at least for now), since the same code is always used when a new plugin slot is chosen, no matter if via mouse click, keyboard or wheel.

<blockquote>
While i don't really like the Transpose contextual menu compromise (i still think +/-4 and +/-7 are common enough to warrant their entry into the list), at least the Transpose dialog uses the mousewheel to scroll quickly thru the values to get what i need nearly as quickly as possible.</blockquote>
Also unrelated, please comment in the appropriate issue/thread. But as a quick answer: My argument remains valid: +4 or +7 might be common for <em>you</em> - I certainly rarely (if ever) use those amounts. You might want to assign a keyboard shortcut to the "Transpose Custom" command, so that you don't have to fight your way through the context menu - All you'd have to do is hitting the shortcut, entering the amount and pressing Enter then.

<blockquote>With this new capability, perhaps we can have a preference to opt out of spin arrows (those elements are simply not drawn). </blockquote>
And the advantage of that would be...?

I know some of the issues were not related directly to the original FR, but i figured i'd put all the testing i did with the mousewheel in one thread, so you/we can refer to this later if needed.

Just mentioning the plus/minus of the mousewheel in the dialogs. My point was not to complain that i couldn't get what i wanted, but to remind users and future devs that the mousewheel in the Transpose dialog makes for a nice consolation prize, as it were. I didn't even pick up that the Transpose dialog had a keyboard shortcut. That's an even better option, considering.

I am always all for reducing unnecessary visual clutter for GUI that a user opts out (leftover trait from my Mac days). Wishful thinking on my part, i admit. I can see by your question, that as the programmer, testing for GUI options and deleting elements on a case-by-case basis better be worth the time it takes to assemble the methods....;D

Overall, good job. And feel free to consider this FR "resolved."

If there's any more dodgyness showing up with the controls, let me know.