I don't know much (if anything) about it, but it can be turned into an interesting thought experiment.
Let’s use Apple as an example, as they tend to do major transitions on a regular basis.
So, let’s say that the top tier already approved the new security mode(l).
Now, how to do it?
My understanding is that most if not all APIs would have to be changed or replaced. So that's pretty much a new OS, that needs new apps (if the APIs change, you cannot simply recompile the apps).
Now, if you expose the existing APIs to the new OS/apps, then what's the gain?
And if you don't expose them, then you basically need a VM. I mean, I don’t know Darwin syscalls, but I suspect you might need new syscalls as well.
And so you end up with a brand new OS that lives in a VM and has no apps. So it's likely order(s?) of magnitude more profitable to just harden the existing platforms.
We don't have to theorize. MacOS has TCC, which was first added in 2012 in Mountain Lion and later versions added more grants. It's not a proper capability system, but it's still a security system that came after traditional Unix primitives. Later macOS versions added a sandbox as well, and programs can't reach outside of that sandbox willy nilly. So macOS programs can't navigate to ~/Photos without the user hitting allow, possibly in system preferences, not just as a pop-up.
The external APIs themselves haven't changed. Without recompiling, if I want to enumerate photos using the appropriate framework, the newer version of the framework code will ask the TCC system which popups up a "allow access to Photos" dialog. If my program tries to read the photo db file with a standard open(), it's going to get permission denied. (you can grant programs full disk access of you so choose.)