The current problem with context_id is that people have inconsistently used it as a proxy for a true parent_id, which has led to long discussions in the past regarding the pros and cons of doing so.
But we're going to have a REAL parent_id in acs_objects in 5.2 and context_id can be used for its real purpose: inheritence of permissions.
Now ... two quick points ...
1. If we only had PG and tree_sortkeys we wouldn't need a parent_id as the sortkey encodes the set of parents (and this leads to very quick queries when you want the set of all parents, faster than CONNECT BY as no internal joining is involved). But that's neither here nor their given our Oracle non-sortkey implementation and, IMO, the disadvantages of sortkeys in other areas.
2. Moving out context_id will get rid of certain triggers and, IMO, make the permissions inheritance API more obvious (at least there should be no excuse for confusion with a physical parent_id if we adopt this suggestion after I TIP it, oh, later this spring). It will allow multiple inheritance hierarchies with no extra cost in terms of query complexity/execution times I believe ... so we can decide on whether or not permissions would benefit at that time.
