I'd like to clarify too. The keyboard 'navigation' as I have referred to it will both select and focus a button, not just transfer focus while awaiting selection via a mouse click or SPACE key press. Focus can still be transferred with the TAB or SHIFT+TAB keys as usual (when the 'intraGroupFocusTransferEnabled' property is set).
This solution delegates to Component#transferFocus(FocusTraversalDirection) when the 'intraGroupFocusTransferEnabled' property is false. It is used to determine how focus should be transferred away from the group, treating the group as a single entity for focusability via the TAB/SHIFT+TAB key presses.
Maintaining a single List of Buttons is not much of a chore, and serves to keep all the logic in one place. I did consider changing ButtonGroup's internal collection to a List (enforcing uniqueness) from a Group so that RadioButtonGroup could reuse it too. However the few LOC that might be saved didn't seem to warrant it, and it didn't smell right!
The 'Container 1' to 'Container 6' scenario (from the previously mentioned demo app) uses a RadioButtonGroup to allow RadioButtons to behave as a group (with keyboard navigation) even each buttons is in a different container. I can't see how Component#transferFocus would help in this case, but I don't think you were considering such a scenario.