Managed Update of Intune Win32 App

I deploy 1Password via Intune, and I recently transitioned our deployment from the MSI installer to the MSIX installer—as a Win32 app in both cases. I prefer to manage the deployed version and so disable Auto Update. When deploying using the MSI installer, I used a File detection rule that checked for the presence of the app and also checked the version.

Rule type:          File
Path:               C:\Program Files\1Password\app\8
File or folder:     1Password.exe
Detection method:   String (version)
Operator:           Greater than or equal to
Value:              8.x.x

Associated with a 32-bit app
on 64-bit clients:  No

With this process, when I updated the installer version, I would update the version value in the detection rule, and Intune would update the installed version of 1Password when it detected a version number less than the expected value.

Because the detection script provided for the MSIX deployment—AppDetectScript.ps1—does not include a version check, updating the installer version has no effect on devices where 1Password is already installed. Intune will report that the latest version is installed, but that is only because it is finding 1Password, not because it is finding the latest version of 1Password.  I modified the script to include a version check, in hopes that that Intune would then behave as it had with the MSI installer, installing the latest version of the app when it detected that the installed version did not match the target version.

# Modify the $targetVersion to ensure app updates
$targetVersion = "8.12.10"
$targetVersion = [Version] $targetVersion.ToString()

# The unique 1Password identifier in detection scripts.
$targetPackageFamilyName = "Agilebits.1Password_amwd9z03whsfe"

try {
    # Per-user install (eg. Install behavior in Intune is User).
    $package = Get-AppxPackage | Where-Object { $_.PackageFamilyName -eq $targetPackageFamilyName }

    if ($package) {
        $ver = [Version] $package.Version.ToString()
        Write-Host "1Password is installed."

        if ($ver -ge $targetVersion) {
            Write-Host "1Password is up to date."
            exit 0
        }

        else {
            Write-Host "1Password requires an update."
            exit 1
        }

    }

    else {
        Write-Host "A 1Password installation wasn't found."
        exit 1
    }
}
catch {
		Write-Host "An error occurred when detecting a 1Password installation: $_"
    exit 1
}

As far as I can tell, the detection script worked, in the sense that it started registering the app as not installed—"The application was not detected after installation completed successfully"—but it did not cause the installed version to be updated. 

I know that the https://support.1password.com/deploy-1password/?windows#step-1-plan-your-deployment-windows states:

• To allow your team members to update 1Password, deploy the MSIX as a Win32 app and set the install behavior to User.
• To manage and deploy updates to 1Password, deploy the MSIX as a line-of-business app and set the install behavior to User.

But all of our other Intune app deployments are Win32 apps, and, https://learn.microsoft.com/en-us/intune/intune-service/apps/apps-win32-troubleshoot#:~:text=If%20you%20mix%20the%20installation%20of%20Win32%20apps%20and%20line%2Dof%2Dbusiness%20(LOB)%20apps%20during%20Windows%20Autopilot%20enrollment%2C%20the%20app%20installation%20might%20fail., Win32 and LOB apps do not mix well when using Windows Autopilot (which we do):

If you mix the installation of Win32 apps and line-of-business (LOB) apps during Windows Autopilot enrollment, the app installation might fail.

I was hoping it might just work. Since it seems as though that is not the case, I was wondering if there is a technical reason why the MSIX deployment does not work as the MSI deployment did, if there is a chance that modifying the detection script in some way could work, and, given the answers to the first two questions, if there is some way this setup might be made to work in the future?