@Saga Musix has noted that it looks like there is a bug with the list item selection; by default the first command should be chosen from the list but it currently isn't. This will be fixed in the next release.

In regards to the control state issue @Saga Musix notes that This is an unfortunate clash between usability with the mouse and accessibility. It is impossible to tell whether a checkbox or button was clicked with the mouse or activated by a keypress, and in this case OpenMPT favors the use of the mouse and immediately returns the focus to the pattern editor, because this is what mouse users would typically expect.
Unfortunately we never found a good solution for that which would work both for mouse users and keyboard users. However, I suppose that for most users that rely on keyboard navigation, assigning these actions to a keyboard shortcut would make much more sense than following through a long tab chain every time they want to toggle those options.
I think I now have a workaround that should make everyone happy. Depending on whether the last received input event is a keyboard or mouse event, interactions with controls in the "upper" editor now won't return the focus to the "lower" editor. So for mouse users everything should stay as it was before, and if a button was activated through the keyboard, the focus will stay on that button. This will also end up in the next OpenMPT release.