I don't understand why you say you have to have a supertype of acs_object. Check out the dotlrn sources. The hierarchy there is membership_rel->user_profile_rel->dotlrn_user_rel or something along those lines.
You need to derive from membership_rel in order to get the semantics associated with that kind of relationship. If you do so you can then do the permission stuff you apparently want to do. The permission system answers the question "can party foo do action bar to object fubared" and knows about the special membership_rel and composition_rel relations, returning true if the party has the permission due to belonging to a group or relationship segment that has the permission.
If your parent_rel and coach_rel relations are drawn from the same group, use two relationship segments to gather the two sets into two parties "coaches" and "parents". Relationship segments can be thought of as being subgroups ...
Why do membership_rels and composition_rels have separate tables even though there's nothing in them other than the id field? Because the acs_objects system doesn't allow one to reuse type info tables in derived types, which is something I'd love to fix and probably will someday unless someone else beats me to it. If I'm deriving from a type and am not adding new columns - a perfectly normal thing to do in object oriented programming - I shouldn't have to provide a dummy table.
Why would you use a separate mapping table since both tables have object ids as their primary keys and they're the same key value for the parent type table and the child type table? Maybe I don't understand the question.
The roles are useless IMO. I imagine they were there originally so you could answer the question "which members of Group A have role R?" but relationship segments allow one to answer that question in a slicker way. But bear in mind that relsegs were added after the original ACS 4.0 was released (not until 4.2 I believe) ...
acs-rels are of heavier weight than necessary for group/subgroup management because there's no need for each row to be an object in order to implement the given semantics. However there are cases where it makes sense so it would be wrong to toss out the heavyweight model. On the other hand (as has been covered in other threads) it might be nice to have two variants of a relationship facility for objects, one lightweight to complement acs-rels. The content repository has such a facility ... I'd say this is fairly far down any reasonable sense of priorities, though.
