The problem is that you need some form of RTTI that allows object serialization. This is basically what Delphi does: the forms, controls, etc you are editing are not fake stand-ins, they are the class instances you are working with. The object inspector shows you the actual instance properties as defined in code and you are editing live objects - the only difference is that those objects have a "design mode" flag so they can ignore any user input. When you save a form, it serializes the objects on disk. That serialization data is stored on the executable and when you run the program, the form is deserialized and the object instances are what were stored.

There is almost no UI-specific functionality there, the same functionality can be used to serialize any type of object and you can even implement your own serialization logic for your objects. The language's RTII allows for declaring properties (think like C# properties, though really C# properties were inspired by Delphi properties as the latter had them since the original Delphi 1.0 for Windows 3.1) as part of a class and has support for metaclasses (classes are instances themselves of a metaclass that describes the class), including virtual constructors (since classes are instances they have their own VMT) which allows for constructing class instances on the fly by passing a class type in a function.

The thing is, C++ does not have this sort of functionality. You can implement your own RTTI, as several projects do (many game engines do that for example), but it is often clunky (e.g. relies on macros, duplicating info, manual registration and/or external tools that parse the code and generate the RTTI boilerplate).

C++ Builder did it because it extended C++ to add that functionality in a way that is ABI compatible with Delphi - and is how it can use VCL (which is written in Delphi).

It was easy to do in Win95 through to Win2k because the interface was consistent throughout. Then they started changing the interface guidelines, and toolkit, for every major release of windows; and sometimes several times during the life of a major release.

Similar plan, in 2019 I went back going to distributed systems/Web, where Microsoft technologies are one among many others that get used on a polyglot agency, the usual "A jack of all trades is a master of none, but often times better than a master of one.".

For doing Windows stuff, I would rather advocate for Win32, Forms/WPF.

In regards to C++ stuff, either C++ Builder if it fits the budget, or Qt.

It is quite tragic that even MFC has a better development story than WinUI/C++.

It is baffling to watch community calls and have them talk about rewrites and dropped tooling features as if it wasn't a big deal, being asked for the n-th time since Windows 8.

As noted in some of my comments, the way C++/WinRT have messed up the development with total disrespect for paying customers is incredible.

To come back to your point, the aging MFC has better Visual Studio tooling than C++/WinRT will ever have, specially now after being deprecated.

I would have fired the whole team responsible for C++/WinRT.

honestly using plain win32api or mfc is the most stable bet on the planet