I quote from the link :
- placing them in /S/L/E (or /L/E on 10.11+) and including in kernel cache, makes kextcache do a lot of error checking.
- if you develop kexts, error checking is very important!
comment : Suppose it is true , but the majority of users aren't developers. If there is one , I agree , put them in l/e.
But the error checking is still important.
If I had a dollar for every time a user had incompatible/mismatced kexts in EFI/Clover...
And if those same kexts were installed to /L/E, the user would have had obvious errors from kextcache to investigate.
- some kexts don't work from Clover/kexts (AppleHDA injector, CodecCommander, BrcmFirmware*)
comment :Today , almost every kext can be injected through clover/other , even codeccommander.
FYI: I wrote the special code in CodecCommander.kext that allows it to be used in Clover/kexts. Note that the special code I added to CodecCommander is not present in a kext like IOath3kfrmwr.kext. Note also the case of BrcmFirmwareRepo.kext, which does not work from Clover/kexts, and requires the use of heavy weight alternative in BrcmFirmwareData.kext.
But still not all.
I run into issues that are a direct result of kexts not starting from kernel cache. It is possible these problems are not as prevalent with desktops that have a much simpler hack kexts setup (eg. less kexts, kext startup not as critical).
If you understand the ramifications (including the above regarding mismatched kexts), then by all means put your kexts into Clover/kexts only, but I would not attempt to diagnose a problem with someone doing that, as it is too much work to verify all the kexts in Clover/kexts are compatible with each other (eg. easier to let kextcache check for me).
- the idea behind Clover/kexts is to have a set of *stable* and *minimalistic* kexts that will allow booting of the installer/recovery, not full functionality
comment : As I said earlier , today this method is minimalistic and fully functional as well.
I still like certain kexts, not necessary for recovery or the installer to be out-of-play when booting the recovery or installer.
- so...the kexts there I tend to not update as often and the full set is not there (less unneeded kexts, less problems)
comment : with newer systems like CoffeeLake we often have to try/inject newer kexts.
Well, of course... updating the kexts on Clover/kexts is a different matter.
(I have scripts that do it automatically...)
- placing kexts into kernel cache for day-to-day use is "more native" (as it would be on a real Mac) vs. injection (which is very non-Mac)
comment : In theory maybe. Practically what's the difference?
The difference is in the results everyday, especially on laptops.
You should hang out in the laptop forum for a while and try to help people... maybe you'd understand better.