The ability to nest user groups (i.e., add a group to a group) would make our lives much easier.
One benefit to allowing groups within groups is that groups can be centered around roles, as opposed to project affiliation (which isn't very useful), and we can slice and dice it in a number of different ways without time-consuming, error-prone redundancy.
Figurative Example: The only reason John is part of the Deciders group is because he is a manager. Therefore, we have created a Managers group in FogBugz and made John a member of it. We have also added Managers to Deciders. At some point, John opts to take a different career path, so he transitions to a non-management role. He is therefore removed from the Managers group. As if by magic, his membership in the Deciders group is also ended; this occurs as one atomic step.
Without nested groups, removal of John from Deciders is a separate step (and might, erroneously, never happen). What is the advantage of this approach?
Similarly, if for some reason it is decided that Managers are no longer Deciders, the whole of management can be removed from the Deciders group in one step without error-prone, redundant user-by-user effort.
On the other hand, if John is granted permission to Deciders on an individual basis (as well as indirectly through Managers), then he will be unaffected by the removal of Managers from Deciders. This reason-for-inclusion information is completely lost in the absence of a nestable groups system, and can create a significant amount of redundancy and error.
Another important advantage of nestable groups is that we can create "junction" groups that exist solely to expose all of the users in group A to all of the users in group B, without the necessity for any shared (dummy-) project exposure. This is very useful for project admins, who need to be able to see users in order to add them without involving a full-blown Site Admin.