Q1: So the question is what is the fundamental reason on why the designers chose to have this concept of a single active group even though allowing the user to have more than one supplementary groups?
The original primary purpose of groups in Unix was to allow for sharing of access to files on disks. Within this use case you'd typically be accessing your files the majority of the time, and occasionally be accessing files that were shared among a group of users.
So my suspicion is that it was designed around this model to start. Over time this model has been modified, but the general approach remains intact, that you're in a primary group (specified in /etc/passwd
) and you have supplementary groups that you can be a member of (specified in /etc/group
).
Several of the earlier implementations (such as on Sun/Solaris) included a limit of ~15 groups total that a user could be a member of when using NIS+.
Q2: What would be the issue if all the groups were active simultaneously?
There are a number of system calls within POSIX that expose an API with this design, hence it would probably be a large task to modify it, given the amount of software that's built around it at this point. And there really isn't any reason to change it either.
The other big limitations are the file system and process space. For filesystems, these generally include only a single value for the GID that a given file or directory is to be "grouped" to. Same too for processes that are running. They're typically associated to a single group.
However, this overall approach has been able to adapt to being integrated with Active Directory and other credential technologies over time, so it's a perfectly fine implementation, though a little strange when you first learn about it.
References
= OpenGroup POSIX docs mentioning GID