The issue as described still occurs on 19w06a when mouseWheelSensitivity is set to the default of 1.0.
The issue does not occur when mouseWheelSensitivity has been set to 0.0, however there is then no longer any scroll functionality (i.e. when selecting a multiplayer server or navigating the options menus).
Leveraging this parameter and setting it to a reasonable value, such as 0.3, makes the issue much more difficult to reproduce and seems to be a viable solution. This setting also allows the user to navigate scrollable menus easily, and even navigate the hotbar with greater efficiency.
However, I think it should be noted that some users don't want the latter functionality at all. I think the ideal solution would be, in addition to providing a slider for "wheelbar sensitivity" in Options -> Controls, to provide keymap endpoints for "Hotbar Next Slot" and "Hotbar Previous Slot" which are mapped by default to "Wheel Up" and "Wheel Down". This would allow users to specify alternate keys (such as "[" or "]") or disable the functionality altogether.
However, I think a better way of communicating this issue is that the Shift key has multiple functions, with only a single function listed in Options -> Controls.
The Shift key:
By default is mapped to "Sneak"
Quick-moves an item (i.e. from inventory to hotbar, inventory to tool, tool output to inventory, etc)
Since both of those functions are performed by the same key, the assumption is that if one re-maps "Sneak" to another key, all of the functions that this key performs will carry over to the new key binding.
When in reality, when Shift is pressed during player gameplay it is interpreted as a keypress event but when it is pressed within crafting menus and inventory it's interpreted as a click modifier (SHIFT+Click performs the "Quick Move" function, similar to how CTRL+Click performs the "Split Block" function).
I believe the underlying request here is to expose these click modifiers as re-mappable options in the Controls, perhaps in their own group. If this were implemented it would require the same key to be able to be used for "Sneak" (or any other function) as well as "Quick Move" (i.e. key mapping conflicts should only arise within groups).
The issue as described still occurs on 19w06a when mouseWheelSensitivity is set to the default of 1.0.
The issue does not occur when mouseWheelSensitivity has been set to 0.0, however there is then no longer any scroll functionality (i.e. when selecting a multiplayer server or navigating the options menus).
Leveraging this parameter and setting it to a reasonable value, such as 0.3, makes the issue much more difficult to reproduce and seems to be a viable solution. This setting also allows the user to navigate scrollable menus easily, and even navigate the hotbar with greater efficiency.
However, I think it should be noted that some users don't want the latter functionality at all. I think the ideal solution would be, in addition to providing a slider for "wheelbar sensitivity" in Options -> Controls, to provide keymap endpoints for "Hotbar Next Slot" and "Hotbar Previous Slot" which are mapped by default to "Wheel Up" and "Wheel Down". This would allow users to specify alternate keys (such as "[" or "]") or disable the functionality altogether.
This is still an "issue" in 19w06a.
However, I think a better way of communicating this issue is that the Shift key has multiple functions, with only a single function listed in Options -> Controls.
The Shift key:
Since both of those functions are performed by the same key, the assumption is that if one re-maps "Sneak" to another key, all of the functions that this key performs will carry over to the new key binding.
When in reality, when Shift is pressed during player gameplay it is interpreted as a keypress event but when it is pressed within crafting menus and inventory it's interpreted as a click modifier (SHIFT+Click performs the "Quick Move" function, similar to how CTRL+Click performs the "Split Block" function).
I believe the underlying request here is to expose these click modifiers as re-mappable options in the Controls, perhaps in their own group. If this were implemented it would require the same key to be able to be used for "Sneak" (or any other function) as well as "Quick Move" (i.e. key mapping conflicts should only arise within groups).