One significant difference is that Metro/UWP requires signing for pretty much everything. Without signing you can't have package identity, and without package identity, you can't even use the UI system. Furthermore, it requires a paid cert, which is expensive and requires publicly divulging your identity. I have major problems with this as it opens developers up to harassment. .NET at least allowed self-signed certs.
It's true that there is no great answer for how to add capabilities and sandboxing after the fact. But what Windows did was build an incredibly restrictive sandbox and then tell everyone who couldn't accommodate even one of the restrictions was "sucks to be you". The result was that developers, when confronted with "all or nothing" for Metro-style apps, were forced to choose nothing. It was also not a good look that Microsoft's own flagship applications like Visual Studio and Office did not show any progress toward adopting UWP, and in the latter case, was specifically exempted from the Windows RT restrictions to continue using Win32 on that platform.
If there had been a better strategy for easing in UWP technology, we might have seen better progress on adoption of Windows Runtime APIs and capabilities so new programs could gradually move toward the new technologies and away from HWNDs. Unfortunately, the technical barriers that were put in place between Win32 and UWP are so large that progress toward breaking them down in the Windows App SDK has been slow.
The GAC and certain CAS configurations would require paid certificates, too. Certainly the requirement of paid certificates can be seen as a part of how both of those eventually fell out of favor. That is another of the things I felt UWP missed learning from .NET. Developers do generally dislike code signing certificates and try to avoid them.
Also to be fair, UWP had a rather streamlined certificate system if you targeted only the Store and let the Store manage your certificate chain. It was even a little bit easier to use than Apple's similar App Store management of XCode certificates. Not that that was a high bar to clear.
> It was also not a good look that Microsoft's own flagship applications like Visual Studio and Office did not show any progress toward adopting UWP
There was some progress. Office involves a lot of teams working at different paces and sometimes extremely different codebases. OneNote was fully UWP for a while and was at one point considered a flagship and testbed for UWP "Fluent Design" (both before and after the shift from touch-first to the over-correction to "it's just a desktop framework that sometimes is touch friendly"). Several new Office apps were written UWP first, including the "Office Hub" app that became called just "Office" and now is even more confusing called "Microsoft Copilot 365 app". "Outlook (New)" has always been React Native, but as a React Native project, it ran entirely in UWP, too, for a while. It was said to have been one of the drivers for deep UWP support in React native at the time. There were also the React Native-based Word, Excel, and PowerPoint "mini" versions that ran entirely in UWP. Those are said to have influenced more of the real codebases pushing towards React Native, but did not try to replace the original codebases in the same way that "Outlook (New)" today is overtaking "Outlook (Classic)".
There were a lot of strategy problems with UWP, but adoption was further along in some areas than it looked.
It's true that there is no great answer for how to add capabilities and sandboxing after the fact. But what Windows did was build an incredibly restrictive sandbox and then tell everyone who couldn't accommodate even one of the restrictions was "sucks to be you". The result was that developers, when confronted with "all or nothing" for Metro-style apps, were forced to choose nothing. It was also not a good look that Microsoft's own flagship applications like Visual Studio and Office did not show any progress toward adopting UWP, and in the latter case, was specifically exempted from the Windows RT restrictions to continue using Win32 on that platform.
If there had been a better strategy for easing in UWP technology, we might have seen better progress on adoption of Windows Runtime APIs and capabilities so new programs could gradually move toward the new technologies and away from HWNDs. Unfortunately, the technical barriers that were put in place between Win32 and UWP are so large that progress toward breaking them down in the Windows App SDK has been slow.