I can agree with this. I've always said that the concept of Linux needs to be a centralized experience for most, and then diverging distros for those who want to seek them for others. Like when you install Linux for the first time, it's just called "Linux". That's the name of the distro. And it is a collection of all the other OS's most popular features. It is the default linux experience. If YOU want to change something, you can, but most won't. Windows 95 and later were actually pretty customizable, but how many people actually customized their window colors? I knew a few people who did. Most didn't.

And that's the thing about this kind of mass appeal that linux would experience. Terminal would still work, just as it does today, but it wouldn't be the default behavior for most. Terminal is the second biggest reason people don't use linux.

So for there to be a singular starting experience, it needs to basically be "This is linux. You've never used it, but you already know how. All your programs from mac and windows work here. Plus it's free, and more secure without ads or tracking."

That alone would be the driving force. Once they're into the ecosystem, they can play with terminal if they want. They can customize if they want. But I have a feeling that most would stay with whatever the default experience was for their entire time using the system.

And the part where "all your apps work" is part of what I'm talking about with everybody catching ReactOS to modern. It's not modern right now, but that's due to lack of development. I'm saying with a huge development increase, it could be a small part of what makes your vision of a popular linux a reality. One of many moving parts basically.

I think, your expectations are off for what a native integration would achieve. A kernel which has both a Linux API and a Windows API would be an insane maintenance effort. You'd naturally want the Windows APIs to simply be translated to the respective Linux API calls. This is what WINE does.
In theory, if it's directly integrated, you could do some dirtier stuff, i.e. call kernel-internal APIs, but you want to avoid that as much as possible, since those kernel-internal APIs are not nearly as stable as the public APIs.
It should also be said that writing kernel-level code is hard. You cannot ever crash, you cannot ever make mistakes when managing memory, you cannot allow yourself any vulnerabilities. Again, you want to avoid writing kernel-level code, if you can.

WINE has some additional ugly workarounds, like a virtualized filesystem. There's not terribly much you can do about that. Windows applications may simply expect certain folders to be in certain paths. You can't directly map that to a UNIX filesystem.

As far as I can tell, pretty much the only advantage of natively integrating it, would be that it's installed by default, which can be achieved in other ways (distros), and due to those ugly workarounds will not be popular at all. As much as I'm touting its horn right now, I do not want WINE on my system, unless I need it.

It's easy to be frustrated with WINE, because it does not handle all applications perfectly, and then think that the approach is just wrong. But yeah, no, some really smart folks came up with that approach. It's just insanely hard to get the exact (undocumented) behavior of the Windows kernel APIs correct, whether you do a mapping or implement them natively.

1. Microsoft hasnt sued ReactOS only because its not significant enough for them to care about (a few Windows devs have confirmed that some ReactOS code looks stolen)
2. Companies have no reason to fund it, wine does everything they need plus enterprise software is being produced for Linux
3. Regardless of how "clean" ReactOS is they cannot legally reverse engineer Win10 or Win11 due to the EULA (which Microsoft would enforce in court)
4. Even if ReactOS has 100% compatibility (highly unlikley) it doesn't means Linux will as well. In addition companies would add checks to drm to ensure a legitimate Windows kernel is used so we would just end up where we started.
5. The only thing we would gain is an open source nt-based system, this would be immediately rejected by the POSIX purists if anyone tried to add it to Linux. Linux isn't Unix based because NT is proprietary, people like the Unix standard.
6. Not only is the means flawed the ends are arguably worse. Linux does not need to be like Windows/MacOS, Linux does not need complete compatibility Windows/MacOS software, and tbh Linux doesn't need more Windows/MacOS users because objectively Linux is not Windows/MacOS. We arent helping older users bg watering down Linux, we arent helping new users by tricking them, and we arent helping future users by convincing them on lies.