Package Identity isn't that different from Signed COM Registration of the ancient past. Microsoft built up a lot of dislike from it by building it "sandbox-first", but the core of it still isn't that different from COM's ancient footpaths, at least to the COM diehards that hate .NET and didn't learn near enough from .NET's battles with the same things in terms of package signing, CAS (Code Access Security), and the GAC (Global Assembly Cache).
"Sandbox-first" even made some sense as a direction to work because it is harder to add a sandbox after the fact than to start with one, which is one of the core lessons learned from XP trying to sandbox some of the insecurities in Win32 and getting caught in a lot of complications. (The "sandbox-first" of UWP wasn't even that different under the hood from the XP "sandbox" of Folder/Registry Redirection, just a little better hardened.) Microsoft needed a lot better messaging up front if they had expected to allow more apps to leave the sandbox eventually. But Microsoft probably did believe the UWP sandbox was a better and safer experience for consumers.
But yeah, what's left of Package Identity outside of the sandbox feels like it includes several classic mistakes from .NET's CAS/GAC era, and also seems to point out that Sinofsky was wrong about WinRT "respecting the past" when it failed to learn from that era because it didn't trust .NET's history.
There are still some things that are still locked in the UWP world that I wish were not.
For example, Windows classic desktop apps still have no equivalent to the UWP app lifecycle. Your UWP app's processes can be suspended and resumed without you writing code to force the suspension and request when to be resumed later. Instead, you are expected to appropriately handle event notifications for suspend, resume, and the app entering and leaving background state.
This system-managed UWP app lifecycle makes life harder for UWP app authors, but I think the net win for battery life is much better for the user experience, which is why mobile apps operate the same way. Yet the docs for the Windows App SDK, which is supposed to bring the best of the UWP to desktop apps, explicitly say that WinAppSDK apps control their lifecycle just like other desktop apps, and the only power friendliness in the WinAppSDK API is voluntary (aka no one will use it). [1, 2]
I'll probably write more soon in response to other parts of the original link's comment thread. Overall, I feel like UWP is being unfairly maligned here, and that while its introduction was unforgivably arrogant, Steven Sinofsky is also right that it was daring and necessary to fix the mistakes and outdated decisions of 16-bit Windows and Win32.
[1] https://learn.microsoft.com/windows/apps/windows-app-sdk/app...
[2] https://learn.microsoft.com/windows/apps/windows-app-sdk/app...
Those are some good points, and I especially loved that lifecycle management in the era where I used a lot of Windows 8 apps. Even on a Desktop with apps filling up my screen still seeing some of them pinned to 0% CPU most of the time (while I'm multi-tasking) in Task Manager was a delightful magic. I also agree that was one of the best parts of the UWP sandbox and one of the biggest shames when Microsoft had to figure out how to allow sandbox breaks that they couldn't find a way to make the lifecycle and other smarts parts of the sandbox more opt-out by default rather than "opt back into the full sandbox". Of course needing to opt-out by default was one of the reasons developers hated the sandbox in the first place. It's a marketing challenge no matter how you slice it.
That relates to some of my criticism that maybe UWP could have used more .NET veterans because that was one of the problems with the CAS sandbox. For the most part the CAS sandbox was "opt-in" and yeah software developers through ego, hubris, and everything else will most often declare "my app/library is a special snowflake and needs access to everything!" So even if things opt-in to additional security controls like CAS, no one tests or builds for Production in a CAS sandbox so even things that claimed to support CAS threw runtime exceptions all over the place to the point no one could trust CAS to the point were CAS died for being practically useless overhead because no one both opted in and knew how to test it.
UWP had a lot of good ideas. It's insistence that it didn't have much to learn from .NET's mistakes was not one of them.