I've not been able to find documentation on how to construct these following LoginName Format

Add-SPOUser cannot assign a site collection administrator because it only adds a principal to a named SharePoint group; Set-SPOUser -IsSiteCollectionAdmin $true is the cmdlet for changing site collection administrator status.^1^^2^

Cmdlet distinction

These are separate operations:

Although the Add-SPOUser summary says it accepts an Office 365 security group, its mandatory -Group parameter is specifically the name of the destination SharePoint group. It has no site-administrator parameter.^1^

Therefore, the command you found is the appropriate operation for site collection administrator status:

$Site = "https://contoso.sharepoint.com/sites/example"
$GroupId = "<security-group-object-id>"
$LoginName = "c:0t.c|tenant|$GroupId"

Set-SPOUser -Site $Site `
    -LoginName $LoginName `
    -IsSiteCollectionAdmin $true

Set-SPOUser requires at least the SharePoint Administrator role. It is not supported with granular delegated admin privileges (GDAP).^2^

A documentation caveat remains: the current Set-SPOUser page describes this operation in terms of an existing user, not a security group. Consequently, your successful security-group command demonstrates current service behavior, but the available official cmdlet documentation does not explicitly establish that group scenario as a documented contract.

Documented Microsoft 365 group claims

The Microsoft 365 group formats you listed are officially documented:

Members:
c:0o.c|federateddirectoryclaimprovider|<group-object-id>

Owners:
c:0o.c|federateddirectoryclaimprovider|<group-object-id>_o

The GUID is the Microsoft Entra object ID of the Microsoft 365 group. The members claim is added as a visible principal to the site Members group. The owners claim, with the _o suffix, is added to the site collection administrators and also as a hidden principal to the site Owners group.^3^

These claims describe the permission integration created when a SharePoint site is connected to a Microsoft 365 group. Membership flows from the Microsoft 365 group into SharePoint; adding somebody only to a SharePoint group does not make that person a Microsoft 365 group member or owner.^3^

Security-group claim documentation gap

The retrieved official material does not document the SharePoint Online encoding:

c:0t.c|tenant|<security-group-object-id>

It does confirm that security groups and mail-enabled security groups are intended for granting access to resources such as SharePoint sites.^4^ However, that does not document how their SharePoint LoginName values must be constructed.

The old SharePoint 2010/2013 encoding article should therefore not be treated as a complete specification for modern SharePoint Online principals. In particular, it does not cover the separately documented federateddirectoryclaimprovider representation used for Microsoft 365 groups.

Requesting the missing documentation

Submit this as feedback on both relevant cmdlet pages:

1. Open the Add-SPOUser or Set-SPOUser Microsoft Learn article.
2. Select Feedback.
3. Categorize it as unclear or missing documentation.
4. Include:
   • The group types tested.
   • The working encoded login names.
   • The exact failing Add-SPOUser invocation and error.
   • The successful Set-SPOUser invocation.
   • A request for a supported table mapping principal type to accepted -LoginName format.
   • A request that Set-SPOUser explicitly state whether security groups are supported as site collection administrators.

Microsoft Learn’s standard feedback system routes content feedback to the appropriate product and content teams; some repositories also provide a GitHub issue option.^5^

References

1. Add-SPOUser-Syntax
2. Set-SPOUser-Description
3. Site permissions after Microsoft 365 group connection
4. Compare types of groups in Microsoft 365
5. Provide feedback for Microsoft Learn content