In my docks in several instances I need command nodes to start some programs.
Then and when I need some nodes which start the program but use specific parameters. Or which open a file which contains some information related to that program. Or which open a file browser which shows the contents of some folders to which the program is related (reading/writing files, backup directory), i.e. several nodes which are somehow related to the program node.
I have 2 options:
1: one menu node in the dock, the menu contains the program start button and all other related buttons.
This requires always two clicks, whatever I do. Since starting the program is >90% this is a significant waste of time...
2: one command node plus 1 menu node. Which is a significant waste of space...

My suggestion/feature request:
a combined command/menu node: clicking on the icon runs the command, clicking on the down arrow opens the menu.

It might be sensual to adapt the clickable areas. Or to use a short/long-click to distinguish. I would not prefer a combination keyboard/mouse or that purpose.

Hi, mouser,
I found some systematic behaviour.
Settings: 6 docks, in the LBC tree consecutively named #1 ...#6, all set to reserve space, all with a hotkey, and set to toggle, no position assigned, all other options = default.
dragging #1 to the left: as expected, a grid is shown, then the dock is snapped to the left screen border and displayed covering the whole height of the screen. A maximized window is adjusted, the left border just snapped to the right border of dock #1.
Dragging dock #2 to the left: a grid is shown next to dock#1, and dock #2 is snapped and displayed as desired, just right of dock #1 and covering the screen full height. However, the maximized window is not adjusted, the left border still snapped to dock #1.
Dragging additional docks to the left: they all are snapped to dock #1, resulting in a stack of 5 docks, on top dock #2. Hiding the docks consecutively reveals that the further ones are in a reverse z-order (#6, #5, #4, #3).
After hiding all docks by assigned hotkey, and restored again reversely, starting with #6, the docks are all displayed, and the maximized window is correctly adjusted (left border snapped to the right border of the most right dock, may it be #6 or #1).
Hiding one of the docks left to the most right dock, let us say #4, the docks right to #4 are moved to the left, #3 is now snapped to #5, maximized window is adjusted: still snapped to #1, adjusted width.
If #4 is restored, it is snapped right to #1, yet the maximized window is not restored. Additional docks which are hidden and the restored are snapped right to #1 in stack as described.

Seemes in total that starting with a second dock snapped next to a first dock these additional docks seem to not reserve the space, unless they are restored in reverse order...

Did not test other screen borders (top, right, bottom).

Hope this information is useful. Could also deliver an easy-screencast-recorder file, but it is about 20MB....