Re: Two different windows are a problem ... so add a third!
Architectually, UWP and Win32 are not compatible. UWP is designed around there being a graphics rendering pipeline, whereas WIn32 has the underlying concept that there is a grid of pixels in memory somewhere for everything, and it is shared between applications.
This can be frustrating at times (e.g., in UWP, most loaded bitmaps are just lightweight handles into GPU surfaces: you cannot access the pixels in a BitmapImage control unless you explicitly render the control into your own memory buffer), but the upside is that the GUI operates tens to hundreds of times faster, never needs buffering, and you are able to offload all GUI assets into your graphics card's onboard memory rather than losing application memory for it.
This approach seems to be a way of re-writing what can be rewritten of the old API using the new architecture, and leaving the rest in a kind of compatibility "island" drawing surface within those new windows.
The closest similar problem was what Apple faced when moving MacOS to the pre-emptive multitasking kernel of OS X in 2000 (at least Win32 was designed with multitasking and thread-safety in mind; Mac Toolbox wasn’t). Apple’s approach was to simply bin everything and tell developers to use a completely new API; an approach that, as I hope is obvious, is something that would never work in the Microsoft ecosystem, where developers have a much more robust and equal relationship with the OS platform vendor.
Biting the hand that feeds IT
