A serious question: what are native controls on Windows? Is the Windows XP era where each control is its own HWND (and usually drawn with GDI+)? Is it Windows 7 era where the drawing is Direct2D? Windows 8 where the elements of the app come together with DirectComposition? Or maybe Windows 10 style which is an evolution of UWP (now rebranded WinUI), with drawing in Win2D?
For lightweight utilities, I think the user32 controls (HWND per control, drawn with GDI) are still a reasonable choice. That's the one GUI toolkit that's guaranteed to already be in the working set on all versions of Windows, thus minimizing the impact on startup time and memory footprint. Do those controls just look hideous to modern users? I obviously can't judge that for myself. Or is there a problem with the way they render text on high-DPI displays?
It used to be they didn't render high-dpi text correctly, but fixes went in for that. Even so, it's a hack and often not pixel perfect. If you're trying to do visually sophisticated things (soft shadows, fading animations), GDI+ is inadequate. So basically it looks antiquated. It might be fine for simple form-like programs.
My main point is that "native" covers a lot of ground, and "native legacy compatibility" and "native modern" are radically different technology stacks on Windows.
The HWND-based ones that come with Windows would be the native controls as this is how the underlying window system works. The WPF/UWP/etc UI stacks are built on top of HWND stuff pretty much the same way as Java Swing or JavaFX were made that largely (especially the latter) ignore the underlying window system.
Of course since they come with the OS you might as well use those instead of bundling a separate UI toolkit, but IMO if you consider them as native as the HWND stuff then might as well consider everything native - AFAIK Windows even comes with a shared Electron/Chromium instance applications can use so in that case you could say anything that uses Electron is native on Windows :-P.
UWP is most definitely not HWND per control, and doing so would be incredibly limiting. I don't know the UWP (WinUI) internals, but on mac it's generally a CALayer per widget, and Core Animation is doing the compositing. On Windows, the Windows 8 equivalent is DirectComposition, but I think the WinRT Windows.UI.Composition interface has some capabilities not exposed through winapi.
It isn't HWND per control indeed, it does its own composition, hence why i mentioned Swing and JavaFX with an "especially the latter" in parentheses (but Swing also does bypass the underlying window system aside from the toplevel stuff for per-control functionality whenever that'd make sense).
