I think you're misunderstanding my comments slightly, so let me see if I can understand. I would like to rewrite the document once the dust settles on our first dotLRN release, in practice after Copenhagen ...
The bug isn't in the way groups and relational segments work. The bug was in the fact that acs-subsite wrongly added a composition relationship to a child site's parent group.
1. A composition relationship between G1 and G2 says "G1 consistes of all [direct] members of G1 and all members of G2". That's it.
2. If you add someone to G2 with a particular membership_rel type (read "role", say "admin_rel") they are added to G1 in the same type.
3. Let's say you have a relational segment called "G1 admins" in group G1 and one called "G2 admins" in group G2, which consist of all the parties in their group with the admin_rel membership_rel ("role"), and that you give the "admin" privilege to those two relational segments. Because of #2 above, anyone made an admin of G2 is an admin of G1.
Now in the subsite case, let "G1" be the main subsite group and "G2" be a child subsite group. If you follow 1-2-3 above, you'll see that adding someone as an admin to the child subsite makes them an admin in the main subsite. Oops!
But there's no bug in the groups datamodel. The fix is simple: there shouldn't be a composition_rel between a subsite's group and its parent's group. Then the 1-2-3 cascade above doesn't happen. And that's what I've done in 4.6.2.
For your use, though, you *want* privileges to cascade, so a composition_rel should work for you, at least if I understand correctly from your note and our previous IRC chat.
Anyway ... does the above help make things clear? Obviously when re-writing the docs I can ignore the acs-subsite bug, if the doc doesn't have to explain the bug it will be a lot simpler! and given that the bug's fixed ...
