At the risk of seeming rude ...
May I suggest that rather than continue to try to make mountains of molehills we concentrate on known mountains?
The permissions system has worked very well for us in nearly all cases. I will lobby extremely hard against any fundamental change of the semantics of the permission system.
As far as making the permissions system work more efficiently without changing the underlying semantics, AFAIC go for it.
However I already know how we can get another large improvement in permissions performance for complex sites, particularly .LRN:
Get rid of custom permissions that duplicate global permissions, i.e. foo_read and the like. A standard .LRN install gives us 69 privileges. I think that could be cut down to perhaps 10 or so.
It is also clear you misunderstand how the permissions system scales today. While the view you mention would grow polynomially if it were materialized, it never is. It's always qualified by specific objects, parties etc.
In this case the two largest tables - the object table and the context hierarchy table - are joined using b-trees.
This means the cost for permissions checking grows at log2(N), in reality there's no polynomial cost involved. If there were, the system would collapse after a few hundred or thousand objects were inserted.
As it is, we're seeing sites with over a million objects that perform reasonably well on modest hardware. Galileo's .LRN installation comes to mind. 1.5 million objects, something like 16,000 users, running on a relatively modest dual P4 Xeon system.
You have to understand that my efforts to improve permissions performance done for 4.6 was my *first* attempt to attack the largest issue, the fact that PG doesn't optimize UNION views and that this, in fact, did lead to polynomial degradation of the performance (PG would materialize the views).
It was never intended to be my LAST effort to improve performance. It's just that performance improved so dramatically that permissions performance ceased to be crisis.
Now that we're starting to see some very large OpenACS sites, particularly .LRN, it's probably become time to look into improving performance once again, but I haven't heard anyone claim that it's a crisis as it once was ...
BTW in practice using groups/roles to assign permissions rather than do so to individuals is actually what we do except for a user's own objects, and a direction we want to continue to move in. This is why we have an admin group built automatically for subsites now (as of ... 5.0 I think?)
This reduces the need to assign individual permissions to users.
It's not dependent on changing the underlying semantics of the permissions system, though, we can have this benefit without making any changes whatsoever in the semantics...
