Thanks for going through the proposal and coming up with great questions @pedroigor, let me go through them:

1. That's it. By adding the namespace field in the database with the full id/path, it should both keep retrocompatibility with existing roles and not add extra overhead to existing queries. When it comes to storage layers, that's where my understand is still a bit limited, so I trust the judgement of all of you more experienced with the codebase :).

2. That's the one where I'm torn a bit. Clients should be part of the hierarchy as roles can be created for certain clients too, but it doesn't fit nicely in a hierarchical representation that this is supposed to create. We can consider a different representation in the UI for sure, or try to think how we could involve clients without putting them in the role path.

3. So for Dynamic Scopes and RAR, there will be a joint proposal to implement them in Keycloak, it will be completely separate from this one. What I tried to surface in this one is that, by having a way to scope the authentication to a certain context, we could use this new roles format to more easily query at the context that we are scoping by. So, yes, this is just a very small nice-to-have for Dynamic Scopes and RAR to make them more powerful when filtering roles.

4. Afaik, composite roles are used to "group" roles together under a single role. So you can just assign a single role to a subject and that subject will also get all the roles associated with it. In my view, namespaced roles could also be composed by others, but we'd need to set some boundaries. For example: If your role is scoped to a certain tenant or group, the roles that compose it will also need to be scoped to that specific context. But we can do some more research on this area.

The multitenancy model is still WIP but I believe the former is the prevailing choice for now, yes.