Site wide admins, for instance, have every privilege on every object. If 'forum_create' is a privilege, the site wide admins have that privilege on every object. It doesn't make sense, but that is join magic at work.
I've pointed out before that roles are needed for fine grain control of what users can do to an object. A rel_segment is not a role (IMO), just a container for who can play a role. The role is defined in the UI. Even if you go to the trouble of granting 'write' on object '1' to a rel_segment, this doesn't define or control what users who are members of the rel_segment can do to the object.
As an example, say we have an news application, for simplicity, just one instance. We create a group G, with rel_segments 'writer_rel', 'editor_rel', 'publisher_rel'. If a user has a writer_rel to the group G, they can create new 'news' objects. Writers and Editors can make changes, but only Publishers can make the news go live.
If you have two instances of the news package, you might write it so that new news items have the context_id set to the package, and assign permissions on the package_id of the news package (that is assign read, write, admin to users on the package_id), not on the relational segments. So that even though all Writers, Editors, Publishers might have the 'write' permission on all the news items, each can only do certain things to the items.
