Not sure the link really applies to what I'm seeing. In my case I have a WPF/WCF app that I need a way to web deploy as a stop gap and thus it's a .NET Framework app that I'm hosting on Windows 2016 IIS (any before you think it, I've already worked through the mimetype mapping issues, etc). I'm downloading/installing the appinstaller from the remote server using an FQDN url (inside the network) to my Win10 1903 with sideloading enabled (I downgraded it from Dev to verify for user in the field).
The need to manually create an .appinstaller file is currently done via VisualStudio (but plans to automate via script for CI/CD). With that being said, I do believe you may have triggered something that I missed/wasn't expecting. When I browse to the index.html file with a link to the *.appinstaller, I was expecting this workflow to read/load/execute the .msixbundle from the MainBundle element. While I had manually changed this URL path to reflect the \Download directory change I neglected to also change the AppInstaller element's Uri="" attribute to iwhich was pointing to the older *.appinstaller in the root directory of the webserver.
This too me is very odd as it means the browser is downloading the *.appinstaller file then reading the internal <AppInstaller> element to then read the *.appinstaller file again from the server to launch the *.msixbundle.