back then at my old company we also hit the limitation of the fact that one user can only be in one group. But in that case, it was a very sophisticated permission requirement that surely not the average business application had.
The solution to get over this limitation was that we used the user & groups not as the source entities for managing the permission but instead as target entities. This is a good example where when you need higher-level abstractions, you can generate the target entities on the fly.
In this case, what we did in order to get over the one-business-user-per-constraint-hierarchy was that we for every business employee created multiple
sec$User objects. Those different user objects were put into all the
sec$Group instances that they needed. Then we used the great User substitution feature. With that the business user got the user selection drop-down and was able to switch between the target users. In this case, it actually made sense, because those different user instances, in fact, represented Hats that this business user could wear at a time. But normally the user did not wear two hats at a time.
With this implementation I learned an interesting lesson: the limits of the Platform are actually not just what the basic primitives allow, but they can be remote controlled (as they are just data in the DB) in order to make your own abstractions.
Another example where I remote controlled the CUBA building blocks is the very little known entity pin example: https://github.com/mariodavid/cuba-component-entity-pin. There I dynamically add session constraints programmatically based on some user-interaction (like pinning an entity instance). There the access groups are also just the starting point.
Besides that, I think that in the case of changing the behavior of the access groups and make it multi-dimensional it can get very complicated very quickly. You can see it in the multi roles concept, where it is from an operations perspective sometimes really hard to determine what actual permissions now apply to a particular user. In 7.2 the screen of the “effective role” was introduced in order to mitigate that problem. Back then I even created a dedicated addon just for that very case of managing the complexity (https://github.com/balvi/cuba-component-user-session-information).
For the Access Groups, multi-dimensionality combined with the hierarchical structure will surely make it super hard to understand what particular constraints are actually applying to a particular user.
Also, I think we have to put it a little bit into context here. Comparing CUBAs security subsystem to the golden standard of security in the Java world: Spring security you will quickly see that in a lot of respects CUBA highly exceeds the capabilities of what you can do with Spring security. Even one of the most advanced parts of Spring Security: Spring Security ACL is covered (in a different way) and exceeded by CUBAs security subsystem.
Of course, the security requirements of a business can skyrocket. But then we also have to look at the average (or better the median) security-requirements of a business application. Because flexibility very often comes at the cost of complexity…
Mirroring the behavior of LDAP and with that the behavior of Microsoft Active Directory enables to work a lot of people from the ops domain here. So I think even that on its own has a high value.
I would suggest you that in case you already see that your requirements exceed the limits of CUBA, try to think of how to programmatically generate constraints as I did it in the entity-pin example and apply them on the fly. This way the sky is the limit…