I agree it's confusing. But here's the intention as far as I can tell:
UWP was originally "monolithic" and "closed" in several respects: your app had to either adopt all UWP facets (be a "UWP app") or none (be a "Win32 app"), new APIs only shipped with new Windows releases, the implementations were entirely closed source, etc.
In the past few years they've started to take pieces of what used to be UWP and pull them out into separate components. Unlike the monolithic UWP platform, these components can be adopted independently by Win32 apps without having to adopt all the other components at once, their runtimes can be distributed with your app outside of Windows and run at least a few versions back, their implementations are partly or wholly open source, they do planning and design reviews in the open on github, etc.
So far, the components they've done this with have been
* WinUI (a decoupling of the UWP UI framework)
* MSIX (a decoupling of the UWP packaging system)
* C++/WinRT, C#/WinRT and Rust/WinRT (a decoupling of the UWP object system and language bindings)
The "new" Project Reunion is basically an umbrella name for these decoupled UWP components, a declaration of their intent to decouple the rest of UWP in similar fashion, and a new github repository for planning this and designing the future evolution of the Windows developer platform in general. So the repository has issues posted by Microsoft developers about how the UWP app lifecycle and resource formats can be decoupled, for example.
That's on current WinUI/UWP XAML, the new version in preview (WinUI 3) pulls out components deeper into the stack so it can run a couple more Windows versions back (to 1803 I think)
Having actually tried to use XAML Islands to get some UWP UI controls into a WPF application, I can say that the experience was absolutely horrible and I ended up giving up and not using the UWP control after all. Truly, truly horrible.
UWP was originally "monolithic" and "closed" in several respects: your app had to either adopt all UWP facets (be a "UWP app") or none (be a "Win32 app"), new APIs only shipped with new Windows releases, the implementations were entirely closed source, etc.
In the past few years they've started to take pieces of what used to be UWP and pull them out into separate components. Unlike the monolithic UWP platform, these components can be adopted independently by Win32 apps without having to adopt all the other components at once, their runtimes can be distributed with your app outside of Windows and run at least a few versions back, their implementations are partly or wholly open source, they do planning and design reviews in the open on github, etc.
So far, the components they've done this with have been
* WinUI (a decoupling of the UWP UI framework)
* MSIX (a decoupling of the UWP packaging system)
* C++/WinRT, C#/WinRT and Rust/WinRT (a decoupling of the UWP object system and language bindings)
The "new" Project Reunion is basically an umbrella name for these decoupled UWP components, a declaration of their intent to decouple the rest of UWP in similar fashion, and a new github repository for planning this and designing the future evolution of the Windows developer platform in general. So the repository has issues posted by Microsoft developers about how the UWP app lifecycle and resource formats can be decoupled, for example.