Nested Groups on Unix?

Claus Färber asks: "Is there an easy way to add nested groups (i.e. groups that contain or import user lists from other groups) to Unix account management? While you can manually add all users of one group to the other, it is very hard not to forget to remove or add users to all groups. I already thought of patching NIS modules, providing a PAM module (but will this work with Samba and NFS?) or switching to LDAP (but RFC 2307 does not allow nested groups either...). Has anyone already done this, or are there better ideas?" I've always wondered about this issue as well. Wouldn't extending the /etc/group file to handle nested groups, and the ability to exclude users from groups, be a way of implementing a more finely grained permissions system for Unix?

To understand the advantages of nested groups, I'll use the following example:

Typically, unix groups look like the following:

a: user1, user2, user3
b: user3, user4, user5
c: user6, user7, user8

Now if I want to create a group "d" that is comprised of groups "b" and "c" under most Unices, then you'd add the following line to /etc/groups:

d: user3, user4, user5, user6, user7, user8

Now if I were allowed to nest groups, I could just do:

d: @b, @c

Where the "@" means 'import names from group "b"'.

The advantage of the latter system is that you can add users to group "b" and "c" and not have to maintain the group "d" line as well. Another useful extension would be the exclusion operator, so that if I wanted to remove a specific user from a group (to insure said user isn't included, even if he's a member of an included group) I could do the following:

e: !user1, @a, @b

Instead of manually creating a new list of individual user names:

e: user2, user3, user4, user5, user6

Now you can do something similar to this using NIS and netgroups for large networks, but this feature seems to be particularly useful for the single-machine-large-userbase without the hassle of configuring another service. Would you admins out there find this to be a useful feature? If so, how difficult would it be to modify existing Unix systems to handle these extensions? If not, what reasons can you give as to why future Unix systems should not implement this feature?