Define a relational segment called "Bug Assignees" that draws its users from its parent's subsite membership group (in other words defines a subset of that membership group).
Oops, as you point out, no one can figure out the UI for the subsite and even worse, we're broken in that registered users aren't automatically members of the main subsite's membership group. I have a proposal to straigten this out in mind for 4.7 that I've not written up yet (basically the registered users group should go away and make registered users == members of main subsite).
This is where the dotlrn framework really has done some nice things and where we should be looking for some way to generalize things and apply them to acs-subsites.
For now the best you can probably do is to create a relational segment "bug assignees" that is drawn from registered users, gnashing your teeth at the thought of someday having to provide an upgrade script if we ever get acs-subsite straightened out and you want to scope users to members of the subsite rather than all registered users.
Check out how dotlrn create professors, students etc for practical examples.
It's very fast to generate a list of members of a relational segment ...
I think the MRU idea is really a presentation issue, not a "who can" issue, isn't it? There's no reason why you can't define your own relational segment type that keeps track of the MRU stuff in its type extension table.
