The Zoom release notes are a bit misleading. They didn't enable all virtual cameras, but instead a very specific list of virtual cameras. Here's how you can see that list
strings /Applications/zoom.us.app/Contents/Frameworks/nydus.framework/Versions/A/nydus | grep "Developer ID Application"
I wouldn't fault Zoom for being restrictive about what they include in their allow list, since every addition adds risk, but it looks like they've already included closed-source applications from individuals as of 5.0.5. At least my code is open source and auditable!
Doing that grep interestingly includes "Developer ID Application: NewTek, Inc. (W8U66ET244)", which may match the other comment thread[1] talking about NewTek's NDI Virtual Input (note: the top comment there mistyped "NewTek" as "MediaTek"). So using the NDI solution may work with Zoom without editing entitlements.
Because an app can disable loading libraries/plugins signed with a different developer id certificate, and it seems Core Media IO wants to load the plugin in the actually app process, and it doesn't use an helper process.
The limitation is that CoreMediaIO plugins still run in-process (and not just in some daemon but in arbitrary application processes!), when Apple's direction for over a decade has been to move all plugin mechanisms towards an out-of-process model. There's nothing about video plugins in particular that would prevent them from being out-of-process; in fact, most of Apple's CoreMediaIO plugins already have the bulk of the logic in a separate "assistant" process, but the IPC layer is reimplemented by each individual plugin rather than being done generically by CoreMediaIO itself. It's clear what has to happen, but Apple hasn't done it yet.
This is the downside of a walled garden and locked down devices. Of course many will say its for security and its wonderful but how much freedom are you willing to give up for security?
