Understanding of all the elements of scanCodeStructs_F8C5 enabled me to map out the rest of the keys (i.e. the non-textual ones).  This was quite tedious and there were a few oddities.

The cloverleaf (command, meta) key is ambiguous in the scan code table, and although it has a distinct scan code for the left and right variant, the fact that they both map the the 'left cloverleaf' ADB code makes it ambiguous as to which is which.  So I can only make a guess there.

Similarly, the alt (option) key has the same kind of ambiguity -- there is a left and right variant, but I cannot associate scan code to physical key from the code alone.  The physical distribution of scan codes on the keyboard might usually give some clues (e.g., all the row X items are clustered in an area), but not this time, alas.

(on the other hand, the Shift keys are differentiated)

The return key is interesting.  There is a 'return' key in the usual place, and also an 'enter' key in the upper right.  On PS/2, these behave the same, but under ADB they are distinct key codes, with the 'enter' key mapping to 'numeric keypad enter'.  Who knows why?

Lastly, the pause/printscreen key has a PS/2 scan code of 0x84, which is not valid on scan set 2.  If you're familiar with PS/2, you'll perhaps remember that key is treated strangely, so I'm expecting maybe there is some special code for that.  We'll find out.

I annotated an image of the keyboard with the scan codes overlaid upon the keys.  Along the way I got an unexpected insight.  Because I'm not particularly savvy with the graphics tools, to label the keys with their scan codes I made a 'layer' containing 00 - 7F, and then cut out snippets of that and moved them on top of their keys.  Literally cut and paste.  (I wanted an opaque background to the text and couldn't figure out another way.)  The result is that I have left over a square with holes where are valid scan codes and remaining text for the invalid ones.  Since I serendipitously laid this out rectangularly, I can see some things that were not obvious before.  I had noted in the scanKbd_E5A0: that there was special handling for columns 15, 8, 9, and 6.  Now it is clearer why!

• column 15 has two keys on it -- the two Shift keys
• column 8 has one key on it -- the Ctrl key
• column 9 has two keys on it -- the two Alt keys
• column 6 is treated extra special to test for two possible keys (among the others there) -- the two cloverleaf keys

So the special handling of these columns (generally containing only a specific modifier key) is to set a flag.  Here's the dispatch:

...
E5CB 8C 80 00   cpx     #$8000
E5CE 27 5C      beq     handleCol15_E62C ; col 15 only has the two Shift keys
E5D0 8C 02 00   cpx     #$200
E5D3 27 71      beq     handleCol9_E646 ; col 9 only has two Alt keys
E5D5 8C 01 00   cpx     #$100
E5D8 27 5F      beq     handleCol8_E639 ; col 8 only has Ctrl key
E5DA 8C 00 40   cpx     #$40
E5DD 27 76      beq     handleCol6_E655 ; col 6 has two cloverleaf keys (and some others)
...

and here's a typical example of the handling:

...
E62C             handleCol15_E62C:
E62C 5D              tstb                    ; any col 15? (only shift keys here)
E62D 26 05           bne     col15down_E634
E62F 7F 00 64        clr     bShiftKeyDown_64 ; true if 'shift key down'
E632 20 AB           bra     processKbdBits_E5DF
E634             col15down_E634:
E634 14 64 FF        bset    bShiftKeyDown_64 $FF ; true if 'shift key down'
E637 20 A6           bra     processKbdBits_E5DF
...

with col 6 being just slightly different since there are other keys on that column:

...
E655             handleCol6_E655:
E655 C5 0A           bitb    #$A             ; test only the cloverleaf keys; there are others on this col
E657 26 0C           bne     cont_E665
E659 7F 00 63        clr     bCloverKeyDown_63 ; true if 'clover key down'
E65C 7E E5 DF        jmp     processKbdBits_E5DF
...

So that was a handy find and now I've got more commenting and labeling to do...