ACS Rels seems like the right tool for the job. The advantages:
- easier to tap into for other packages who want to talk to BT
- no real query overhead for simple rel-types. Though you should probably subtype acs_rels to add semantic value to the relationship type, there is no need for your subtype's table to have any new columns, and even less need to join against it. Of course if your new rel-types carry attributes, and you subtype your subtypes, you can get a bunch of joins pretty quick.
The disadvantages:
- Object instantiation/deletion overhead if you have to do a lot of them
- Ups the object count. I'm hoping this is pretty much not a problem anymore.
For what you describe, acs-rels seem like the right thing to do with one exception. I would side with the part of you that suggested using perms instead of acs-rels to define a replacement for the module_users table. The downside for the perms approach would be that if a large number of modules existed within a project, you'd be hitting the db pretty hard on the permissions check for the module list page. I haven't got a good feel for how slow that could make things on the latest OACS, but the flexibility and standard-ness of using perms like that would be an worth it, if it doesn't hurt too bad under real world conditions.
