MS Teams Channels - Yet Another Inconsistency on SharePoint Permission handling

Microsoft introduced Office 365 Groups as overarching concept to bring consistency in Office 365 permission management. Each single Office 365 Group manages authorization to a multitude of diverse Office 365 services (MS Teams, SharePoint Online, Planner, Exchange Online), in theory simplifying on the model in which each tool individual applies its own permission management.

In practice, Microsoft itself struggles with the consistent application of this new permission management model. In previous post I visualized the differences in permission management of Communications Site versus Modern Teams Site. Yet another difference is visible on the level of SharePoint site collection that is associated with a MS Teams channel. In the associated site of the main channel, Microsoft utilizes the concept of Office 365 Groups as overarching permission management. However, in the associated site of any private channel, the notion of Office 365 Group is missing.

Comparision Permission Handling + Management within associated site of Main vs Private Teams channel

Observations:

1. In the associated site of the Teams main channel, site authorization is delegated done via Office 365 Group.
   1. The SharePoint Members permission Group has as single member the Office 365 Group ‘Members’
   2. The SharePoint Members permission Group has as permission level 'Edit'
   3. The SharePoint Owners and Visitors permission Groups are both EMPTY
   4. Instead, the ‘Owners’ responsibility is assigned by having the full O365 Group 'Owners' as SCA
2. In the associated site of a private channel, site authorization is still on named accounts level
   1. The SharePoint Members permission Group has as members the named accounts of everyone authorized in membership in the private channel, both the owners and members of the channel
   2. The SharePoint Members permission Group has as permission level 'Contribute'
   3. The SharePoint Owners permission Group has as members the named accounts of the persons that are owners of the Teams private channel
   4. And these same named persons that are owner of the Teams private channel, are assigned SCA

I think this deviation is driven both by the current situation that Office 365 Groups itself does not support hierachy and subsets, plus the restricted usage scope of a private channel. A private channel is meant to restrict access to certain content in the Teams instance, but it is not meant itself as a container hub consisting of multiple tools. As example, you cannot associate a Planner Plan with a private channel. There is thus in the context of private channels less need for the overarching permission management concept via Office 365 Groups.

A concern with this effectively broken permission management in private channel compared to Teams instance itself, is what happens when on the Teams instance level a membership is revoked. Turns out that on Teams level itself the effect of this cascades to any of its potential private channels: whenever an account is removed as member in Teams instance, the same account is also automatic revoked as authorized member in any of the private Teams channels.