Also, if there is non-profit org work, recall that one can supposedly setup an organization and request a developer fee waiver: https://developer.apple.com/support/membership-fee-waiver/

(no idea how this actually works in practice, wonder if one could wrap open source work under a non-profit organization)

So whilst three is different aren’t the analogues on Windows for 1) and 2)

1) Test signing - do what you want

2) Kernel driver - still possible, needs EV cert?

1) on Windows entails a significant security downgrade, as you cannot just pick custom kernel extension only, with validation by the user. That might however not be important, depending on your threat model.

For 2), it’s borderline impossible to get a driver signing cert for macOS nowadays for individuals, it’s easier on Windows.

Ah yes, that is true, SIP is more granular than testsigning on Windows...

> Apple doesn’t issue new certs anymore it seems

This is not true. kexts are still signed by apple after being submitted and vetted.

Apple deprecated KEXTs[1], but still signs some .kexts they've chosen to grandfather in like macFUSE.

[1] https://developer.apple.com/support/kernel-extensions/

Kexts are not deprecated in general-- only kexts that use deprecated KPIs are deprecated. (The page you link is the list of deprecated KPIs.)

The net effect of this: if something can be done using a System Extension rather than a kernel extension, you'll get deprecation warnings if you try to do it with a kernel extension. Kernel extension points that have not been replaced yet are still valid, will still be signed if used, and will still run on current versions of macOS.

And as far as I understand, disabling AMFI disables code signing support and enforcement completely.

Disabling AMFI is a whole other level of a hammer, that I do not recommend at all on a system that you might actively use.