TL;DR I want to assign a set of scripts that allow me a C4D-globally consistent set of functionalities to "walk the tree".
This has to do with the whole arrow key usability concept. These are bound to the OM, and ONLY to the OM, because they use the current OM's specific settings: they skip objects that are not visible (possibly by layer), and skip child trees that are folded (which is a setting valid only for this specific OM as the folding can be different for each open OM).
Now, if you concentrate only on the OM this makes even sense, for the most part: the tree structure is treated as a linearized array of visible objects so moving the "cursor" (a single selection) up and down by arrow key just behaves like in a text: next line, previous line, regardless of the tree depth structure. So if you have a child tree open, the down arrow will take you not to the hierarchically next object but to the child.
Now that is not yet an issue. It makes sense in the context of a single OM if you take into account that the "cursor" moves over the visible elements, so it's WYSIWYG. Fine, locally.
-- But now the actual issues I have:
The first issue arises from the present local behavior. The shift-arrow key functionality to expand a selection moves through the unfolded (open branch) children as well; it selects the next visible element which may either be a child or a successor. Yes, this is consistent with the non-qualified behavior, and it is also consistent with the shift-click range selection. I can see the intent.
But it serves no purpose. As far as I remember, I have never encountered a situation where I wanted to expand-select objects in that way. Either I want to select only the objects on one level - then the functionality should not select the children too. Or I want to select the children but not the parent. Or I want to select all the children recursively - for which there is a separate function, and the expand-select wouldn't work because it skips folded branches.
So, it may be consistent but it's useless. I want a different behavior, which I already have scripts for, but I can't assign them in the OM because the arrow keys are hardcoded.
The second issue is the fact that the OM arrow key behavior is local to the OM. You don't have the same arrow key functionality available in the viewport. You cannot recreate the default behavior in the viewport without scripting, because it is hardcoded on the OM and not available as function in the Customize Command window so you cannot assign it yourself globally. And even if you could, the OM behavior is based on the local properties of a specific OM (status of the folded branches) so it would make no sense.
Nevertheless, I like to have arrow keys available in the viewport. E.g. if you select an object by clicking, but you need the parent of that object instead, so you use arrow-left to get up in the hierarchy. (Sure, you can use the Ctrl-right click method but that works only for objects with a visual representation; it will e.g. show you an SDS but not a Symmetry parent or a Null parent.) Or: You want to select some siblings of the object you clicked; yes you can select them all by clicking but it's far easier by using shift-arrow up/down to expand the selection.
Now I scripted that behavior and assigned it in the viewport (global shortcut, actually), no problem. (I will release the 20 scripts for free on Gumroad shortly if you want to have a look what I'd like in functionality.) All is well...
...except of course that the scripted behavior does not extend to the OM, because there the keys are hardcoded, and the OM-specific functionality can neither be overridden nor removed. So I now have arrow keys that work differently depending on what window is active.
We can argue a lot about whether the arrow keys in the OM are more intuitive the way they are... and I might even agree, and limit myself to overwriting the useless shift-arrow key selection expansion, and add some Ctrl- and Alt- combinations for additional functionality. But I can't even do that! Because the hardcoded functions trigger even if Ctrl or Alt are pressed, and eat up the keystroke for themselves instead of calling the script with that qualifier. So, you cannot add ANY arrow key assignment to the OM. ARRRGGH!
Which brings me directly to the third issue, and I would even go so far as call it a bug. Ah feh, I'd call the 2nd issue a bug already.
Try assigning a global multi-key shortcut using an arrow key in the Customize Command window. This works, e.g. S~Right to select the child of the currently selected object (one of my scripts, but you can use any other command). Do it in the viewport. Null problemo, works fine. Do it in the OM. ...
... it gets weird after opening the tooltip that shows all the followup keys for this multi-key shortcut. Pressing the arrow key (although listed correctly in that tooltip shortcut list) triggers the OM's hardcoded functionality but does not close the tooltip. Pressing the arrow key again closes the tooltip, triggers the hardcoded functionality again, but leaves the internal keystroke system in a curious state, because when I try it again, I see the tooltip for S~S, which probably means that the system still remembers the S stroke from the previous time, and now adds it again.
Okay, it's something I can live with, at least it doesn't crash. But I don't see why the OM arrow keys are hardcoded at all, instead of working the same way any other functionality works with keyboard shortcuts. There doesn't seem to be anything special about them. (Yes, they use the current OM state but that should not be an issue for a Maxon programmer who has all the neat functions to determine the last used OM - which I don't have as the API doesn't reveal them.)