I think the "focus" list should not be maintain over add/remove, but be detected by traversing the tree dynamically.

I mean, wherever you are, if you want to go to the next focusable element, you can iterate to the widget tree until you see one of it.

Trying to maintain a list of focusable is hard and should be add/remove widget resistant, which would be only used if the user use focus ability.
Dynamically iterate the tree might cost a little more, but far more easier to write.

In my point of view:

- In the current implementation: there is no need to have a "focus_previous / focus_next". Instead, we could have method for determine traversing the tree to dynamically determine it.
- Something might be crutial for the implementation, is the ability to pass a focus_index (same as index= in HTML). If we want to go on that way (dunno if it's preferable or not), then obviously, we need a list of focusable index we can search through it. But while index are shared within an html page, dunno how that would work for us (FocusBehavior static will be always here during the app lifetime, so there is no "index" reset like when you reload a new html page.)
- Instead of focus_index, maybe use the "focus_next/focus_previous" to let the user control the way he want the focus. If the user set explicitly a focus_next, and if we want to go to the next, use it.

Advices ?