Lets assume we have party X and party Y. If party X employs party Y, party Y is an employee of party X. And if party X also employs party Z then we need to have the UI be able to list "Employees" and if party Z is also employed by party Q then they are party Z's "Employers." Its this UI view that is the tricky part. It needs to be in a logical easy to read way (for example, having spouse relationship might be more important than mechanic relationship, if its a friends database, so we should be able to have some kind of heirarchy of relational importance in the UI (we might also only care about creating a sortable listbuilder list of rels)... i haven't thought throughly about this so i might be talking jibberish. Note people can employ other people too, there is not just orgs employing people... BUT, what would be really cool (and very difficult from a admin UI perspective) is if a rel type could be bound to a category. So if you set a relationship for Party X employing Party Y it could (if the users chooses) automatically also put party X in the "Employers" category. Stuff to think about...
Anyways, it seems reasonably straightforward programming wise, the trick is in coming up with a simple UI for selecting relational contacts. And also allowing users to create their own relationships (without having object name conflicts and the like). BTW, i would use acs-lang to store transaltions, so the name in the acs_rel_roles should be "MESSAGE KEY MISSING: 'contacts.Employer', etc... this UI is the major difficulty, and where i was really stuck on this issue, and i'm glad that you are taking care of this so i won't think about it too much more :)