Why do Graph PowerShell group commands use different patterns?

Part of the mismatch comes from the underlying Graph API. Reading a relationship and creating one do not necessarily use the same endpoint shape, and the PowerShell cmdlets expose those operations differently. The generated cmdlets can also be uneven, so similar names do not guarantee similar parameters.

For a specific operation, check the cmdlet's syntax and examples with Get-Command and Get-Help, then verify the matching Graph API request. Some group relationship operations take a directory object ID, while others use a reference body containing an @odata.id value. Treat each operation as its own case rather than assuming the verbs will line up.

There may be a simpler cmdlet available in your installed module than the reference-based example suggests. Try inspecting the available group commands with Get-Command -Module Microsoft.Graph.Groups and search for the owner-related variants. Cmdlet availability and documentation can be inconsistent, so check what your version actually exposes before building around one pattern.

For scripts that need to be dependable, I would separate the Graph operation from the PowerShell wrapper. Confirm the API endpoint and payload for the task, then test the cmdlet against a non-production group and inspect the result. If the wrapper is awkward or missing what you need, a direct Graph request can be clearer, but it means you are responsible for the request body and permissions too.

Also make sure you know whether you are using the stable or beta module and endpoint. A script that depends on beta behavior may need changes later, and switching versions can expose differences that are not obvious from the command name alone.

Yeah, the naming makes it look like these operations should be symmetrical, and then they aren't. I would keep a small tested snippet for each group task instead of trying to memorize a rule that may not hold across the module.