So I tried out some of these examples. WingetCreate is able to parse all installers from an msixbundle so you only need to provide the installer url once. This is the change I just made in #393 in order to handle both the msix and portable installers in the manifest.

For Microsoft.WindowsTerminal, the following command should work:

 wingetcreate update Microsoft.WindowsTerminal --urls "https://github.com/microsoft/terminal/releases/download/v1.15.3465.0/Microsoft.WindowsTerminal_Win10_1.15.3465.0_8wekyb3d8bbwe.msixbundle"

For the Zoomit example, the real issue is how we handle zip installers. Because we can't know for sure if the user is providing us the same zip for all 3 installers or 3 different zip packages for each installer, it is hard to determine which new installer url should be used to update each installer node. Just wanted to clarify some of your examples, but updating zip installers definitely needs more work/logic.

So I tried out some of these examples. WingetCreate is able to parse all installers from an msixbundle so you only need to provide the installer url once. This is the change I just made in #393 in order to handle both the msix and portable installers in the manifest.

@ryfu-msft IMO that's really a non-obvious behavior as with majority of duplicate InstallerUrls, we use as many URLs as present in the manifest. But even the solution you described doesn't seem to be applicable everywhere. This will only work if the msixbundle in the manifest is used for as many architectures as it supports (which to be fair is the majority of cases currently). I found that this doesn't seem to work in the example of Microsoft.PowerShell or Microsoft.PowerShell.Preview.

The manifest contains 4 installer nodes, with 2 MSIs and 2 installer nodes having the same msixbundle URL. The following command (using msixbundle URL once) also leads to the same error:

wingetcreate update Microsoft.PowerShell -v 60.0 -u "https://github.com/PowerShell/PowerShell/releases/download/v7.3.4/PowerShell-7.3.4-win-x64.msi|x64" "https://github.com/PowerShell/PowerShell/releases/download/v7.3.4/PowerShell-7.3.4-win-x86.msi|x86" "https://github.com/PowerShell/PowerShell/releases/download/v7.3.4/PowerShell-7.3.4-win.msixbundle"

The reason seems to be that the msixbundle contains installers for all architectures i.e., x64, x86, arm64, arm but the msixbundle is only used for arm and arm64 in the manifest.¹ This would result in wingetcreate matching 2 MSIs and then 4 installers from msixbundle making total of 6 installers in program logic when in reality they're only 4.

Although it's possible but admittedly rare ² that publishers don't want to use MSIX for certain architectures even if supports it for whatever reason so I would understand if we don't want to handle this case. I'm more worried about the UX and the non-obvious part of the situation because it's different from how we currently handle duplicate URLs in the manifest for other InstallerTypes. Maybe we need to have better error messaging / docs to inform the user?