The following T-SQL code creates database users which map to the Windows groups. Every member of those groups, when logging into SQL Server, will have the rights of those database users.
CREATE USER TestSQLDBadmin FROM Login [Domain\TestWindowsDBadmins];
CREATE USER TestSQLDBreader FROM Login [Domain\TestWindowsDBreaders];
Thank you. So if Disney gives Mickey Mouse the ability to fly, every member of The Mickey Mouse Club gains the same ability. Interesting, and entirely confusing. I think I'm not a dba for a reason.
Actually it was the group Domain\TestwindowsDBadmins which was given permission to fly (in the form of the database user TestSQLDBadmin) not the individual member of it. Permission for that group to fly was recorded in the database, and was not removed. What happens is that when the sql server login for the group is removed, that login can no longer be used for the group members to login. If however a group member can login to SQL Server for some other reason that member is still able to do whatever that database user, which has not been deleted, can do. This is because their Windows security credentials say that they are part of the group which is mapped to that user. Someone can still log in if an SQL login has been created for their individual windows login, or if they are a member of some other windows group which has an SQL login, as they are here.
So yes, this is slightly odd (my own first reaction was that it was a bug, but then I realised that it's actuall pretty useful, although not well documented) - but it isn't a case of giving permission to a member and having that extend to the group as you appear to believe, the permission was given to the group in the first place.