The feature I propose is best described with the following example.

There are several braille displays with function keys assigned to specific keyboard modifier keys, one of which is the Hims Braille Edge. This display has 8 function keys, from left to right meant to be assigned to Esc, Tab, Ctrl, Alt, Shift, Insert, Windows, and the application key. This display also has two circular groups of four buttons, meant to be arrow keys.

The mentioned braille display function keys are especially handy if you combine them with other function keys or arrow keys. So when you press advance4 (ctrl) + advance1 (tab), you should be able to simulate the ctrl+tab gesture on the keyboard.

IN the current situation, every single combination has to be manually defined in NVDA. Thus, if you assign br(hims):advance3 to kb:control and br(hims):leftSideLeftArrow to kb:leftArrow, the combination advance3+leftSideLeftArrow isn't automatically assigned to kb:control+leftArrow, unless you specifically do this, either manually or in the driver itself. Especially the in-driver assignments consume a lot of code and are error-prone, since both the keyboard key and braille key assignments reside in strings and there is currently no meganism to test them other than with the braille display in front of you.

This leads to the idea of adding a way to use braille display keys assigned to keyboard modifier keys as modifier keys themselves. In the case of Hims, if advance3 is assigned to ctrl and advance4 to alt, br(hims):advance3+advance4+leftSideLeftArrow should sum up to kb:ctrl+alt+leftArrow without the need of manually assigning this combination. Using these modifier keys in other composite key strokes (containing arrow key emulators or even braille input combinations) should be possible without manual assignments. This would open great possibilities, pressing key strokes like ctrl+c, ctrl+v, ctrl+space without keyboard intervention and manual assignments.

I understand that this proposal can conflict with current key assignments in certain display drivers, which is a point to discuss. I see the following options:

1. Always give assigned combinations precedense. When advance3=ctrl and leftSideLeftArrow=leftArrow, it should be possible to assign advance3+leftSideLeftArrow to something entirely different, like moving the review cursor left
2. Ignore those assigned combinations. If advance3+leftSideLeftArrow is assigned for moving the review cursor left, that assignment should be ignored and the combination should consistently simulate ctrl+leftArrow

In other words, point 1 stands for freedom, point 2 stands for concistency. Since I see reasons why both options could have preference, I would vote for making this an option in the braille settings dialog