I would advocate not mapping the names 1:1, the tabster naming kind of assumes you have some background into focus management.

something like useFocusableGroup or smth like that could work

I totally agree, went with it for lack of a better name.
I'll change it to useFocusableGroup.

Also changing the enum to FocusableGroupTabBehavior to be more descriptive. Not a big fan of the big name but this way we can prevent possible collisions.

Do we need to redefine this enum? Couldn't we simply reuse the type already provided by Tabster?

We could, but needing to import tabster separately just for the types seemed like a bad DX for me. Plus, we can give it a more user friendly name.
Are there any downsides to this?

I would say let's get rid of enums , they are not consistent for the API surface of our library that generally uses string values

take a look at useArrowNagivationGroup and how string props are mapped to the enums

@andrefcdias sorry, I did not construct my intent clearly enough. My idea was to re-export the type from Tabster, instead of redefining it. That way it's still accessible directly from react-tabster package, but in case Tabster decides to add another option to the enum we don't have to go and update types in this package as they are still passed in directly.

Enums are also compiled into non tree shakable code, TypeScript playground

export var A;
(function (A) {
    A["Foo"] = "foo";
    A["Bar"] = "baz";
})(A || (A = {}));

I'll go with the string option then to match the API surface, like useArrowNavigationGroup