Running GUI Linux in a virtual machine on a Mac

That's a misunderstanding of what I was trying to convey. To clarify - I was specifically talking about existing application firewalls and VM applications for macOS that use / used kernel extensions and already have a large userbase on macOS. Their popularity, and relative stability of the kernel extensions these applications used, is proof that Apple's black and white approach of "all non-Apple kernel extensions are bad" is rubbish. Especially when we consider how such a move is also anti-competitive and anti-consumer, and thus helps Apple's business.

Forcing developers to make an expensive migration from their own tried-and-tested and stable codebase over which they have full control, to use Apple's OS API's is a developer hostile move. Even more so when you consider that a developer will now have to rely on Apple to fix bugs or add new features - which Apple may have no inclination to do so so if it feels it isn't aligned to their own business interest (thus anti-competitive).

I personally have been using some of these applications that install custom kernel extension, and my macOS (3 versions of macOS over a period of a few years) has never crashed or become unstable because of them, so far. If an application that used a kernel extension made my system unstable or crashed it, I obviously wouldn't use it and will uninstall it. But completely taking away my choice as user to customise my OS with kernel extensions, and reducing my choices (as a customer) by taking away the ability of developers to offer a non-Apple custom software solution that is better is also obviously anti-consumer.

To be clear, I don't believe there is anything wrong with Apple offering built-in OS API solution for applications like firewall, virtualisation, graphic engines etc. The problem is when they say you can only use those and don't allow competition.

When a particular type of software on macOS is forced to use just one particular API, it stunts all such softwares using the APIS as they can't really offer any major distinction and can only offer the limited features the API provides. Worse still is when such practices is actually meant to restrict competition to protect their business interest. For example, it is clear that Apple is pivoting more and more into commercialising user privacy (monetised through its services) and advertising (by data mining personal data through these same services). In such a case, existing softwares that offer privacy protections (like application firewalls and even alternate operating systems on macs) are examples of competing system softwares that impede this goal. Obviously Apple cannot directly ban these softwares without negative user backlash. But it can ensure that such softwares are crippled by forcing users to use limited API's and / or by limiting the operating environment they run on. (The frog is slowly boiling - https://en.wikipedia.org/wiki/Boiling_frog - and we developers and users are slowly losing more a more control over our Apple computers and device).

I am not at all concerned about the privacy of Apple occasionally verifying the developer certificates I use on my computer. I think they have much better things to do then log this information and try to link it back to me. I mean, if they want to know which software I run they have many more — and much better — options to collect my private data than using OCSP. In the end, this is about trust more than about anything else. A Linux software repository could also be collecting data about which packages you download. Second, OCSP is a standard protocol for certificate checking in the web. I mean, Firefox is using it. So is Firefox bad for privacy now? Besides, I think it's entirely silly to be concerned about OCSP privacy when we have things like unencrypted DNS lookup still being the normality.

Look, I fully understand that some people dislike the idea of their OS periodically checking certificates on their computer. Fortunately, there are plenty of systems on the market that can cater to different needs and expectations. You decide what is a concern for you and what not. If you are privacy-oriented to the fault, you probably want to use some secure version of Linux with IP anonymisers, manually installed software and of course everything strictly audited. Most people don't care about this stuff.

Thats not what they are saying though. They are saying, when we have official userspace API, we will remove access to the old kernelspace API.

Thats not to say the kext is bad or evil. It is to say you won't be able to accomplish it in a kext using public api anymore.

Were there badly written kexts before? Were there kexts with interactions? Were there kernel API and whole subsystems kept in for years because some popular enterprise product refused to update?

Absolutely. I'll refrain from mentioning the one I had in mind which hit all three checkboxes.