I'm so glad to hear that from someone unprompted. I tried WPF and it was a million times harder to use than WinForms, and I couldn't even be bothered to try out MAUI (although I accept it as an apology for WPF lol). I'm still using a WinForms application every day (Git Extensions) and have been able to contribute to it not least because it's the good old familiar WinForms.
This is not to say that WinForms isn't without its problems. I often wonder what it could be like if all the effort of making WPF and MAUI had gone into maintaining, modernizing and improving it.
I think that the native GUI development APIs provided by OS vendors need a kind of "headless" implementation first, where you can build UI in pure code like winforms, and then they should offer a framework on top of that. I, personally, hate XAML. It's stricter than HTML/CSS and very opinionated about how to organize your application. I feel that XAML frameworks should have a common Winforms-like API behind them that you can switch to any time you want. But I've found that using the C# code-behind APIs manually for WPF, UWP, MAUI, etc, is far more verbose than Winforms was.
My only major problem with winforms is that it's still using GDI under the hood which, despite what many people believe, is actually still primarily software-rendered. If they could just swap out Winforms for Direct2D under the hood (or at least allow a client hint at startup to say "prefer Direct2D") it would really bring new life to Winforms, I think.
I would also like a C++ native GUI API that's more modern than MFC
"C# Markup" [1] [2] sounds a lot like what you are looking for. As the only "second party" option in this space it's interesting that it is so MAUI only/MAUI focused, but I suppose that's the "new hotness".
There have been similar F# libraries and third-party C# libraries for a while that seem nice to work with in similar ways.
Unfortunately that is something Microsoft seems incapable of.
MFC was already relatively bad versus OWL. Borland[0] kept improving it with VCL and nowadays FireMonkey.
There there is Qt as well.
Microsoft instead came up with ATL, and when they finally had something that could rival C++ Builder, with C++/CX, a small group managed to replace it with C++/WinRT because they didn't like extensions, the irony.
With complete lack of respect for paying customers, as C++/WinRT never ever had the same Visual Studio tooling experience as C++/CX.
Nowadays it is in maintenance, stuck in C++17, working just good enough for WinUI 3.0 and WinAppSDK implementation work, and the riot group is having fun with Rust's Windows bindings.
So don't expect anything good coming from Microsoft in regards to modern C++ GUI frameworks.
[0] - Yes nowadays others are at the steering wheel.
Borland was pretty good on the GUI front, I think we're forgetting how easy it was to get something rolling in Delphi. It's baffling Microsoft still hasn't gotten their stuff together on this. They've been just releasing new frameworks since the WinRT era and hoping something sticks.
Firstly, that nobody believes them when they swear that {new GUI framework} will be the future and used for everything. Really. Because this time is not like those other times.
Secondly, pre-release user feedback. Ironic, given other parts of Microsoft do feedback well.
Imho, the only way MS is going to truly displace WinForms at this point is to launch a 5-year project, developed in the open, and guided in part by their community instead of internally.
And toss a sweetener in, like free app signing or something.
This is not to say that WinForms isn't without its problems. I often wonder what it could be like if all the effort of making WPF and MAUI had gone into maintaining, modernizing and improving it.