The way Metro apps register themselves was nonstandard prior to their introduction, and the exact details of the API are not actualy documented, and subject to change at Microsoft's whim.
MS document how to register apps, but not how to be on the other side and find which registered apps are registered.
When they add new rules or break the rules, they change the part of the OS which handles the other side to correspond to the new rules (if needed; it may already work as they wanted, but since it isn't documented, anyone else aiming to do the same may work differently up to the point where the difference matters; differences which don't matter are impossible to detect unless Windows goes open source). Once a difference is addef to the OS and discovered, we then need to make changes to accommodate it.
There is no API for a lot of this stuff, other than a very high level one which we can't use everywhere as we need more granular control, due to allowing the user to reconfigure what happens on doubleclick etc. Apps that need more granular control must go through the registry themselves and collate the data, which is spread all over the place and has new rules and complexities layered on top every couple of Windows versions at least. (This part of Windows is an absolute mess, to be blunt.)
A lot of the Windows shell APIs are designed and documented with the assumption that the shell itself is the only thing that will ever be on its side of the API. (Similarly, IE ActiveX plugins were only ever documented from the plugin side, not the host side, and writing an ActiveX host involves months of testing different components to work out the assumptions they make about how and in which order IE does things, none of which are part of the documented API.)
Keeping things like this working when the OS changes them takes research and ingenuity, which means time and money. We aren't in a position to give that away for free to people two major versions behind and using a version that was never supported on an OS version which didn't exist at the time it was made nor through the multiple years that Opus version remained supported with free updates. We give a lot of updates away for free, both fixes and functionality, but there are limits.
Nor could we, when writing Opus 10 over 5 years ago, predict the future and guess that Windows 10 would add new requirements to that code. It is an ongoing maintenance task each time Windows is updated.
We wish it wasn't, and that there were proper, never-breaking APIs and docs, so we could focus on more interesting work, but it is what it is.
Whether you value that work enough to pay for our time more than once every 5 years is entirely up to you.
.