There's also the consideration that software we have to be most careful with is those where we cannot modify the source because we'd have to patch the binary of a closed source application. This is why I find it perplexing that OpenBSD just removed their old systrace AppArmor equivalent.
One thing OpenBSD gets right is marketing. They used to lament the security implications and uselessness of virtualization only to implement vmm. They also used to be vocal about clang not being a viable choice but in light of other alternatives for AARCH64 are on their way of incorporating it into base. I'm not saying this to complain about OpenBSD but merely to make the point that investing in pledge(2) is a hard sell to me personally given their track record. It doesn't confine binaries and I have a feeling they might replace it in 4 years, so I'm wary of carrying an #ifdef path in my own code. With their great marketing, everybody talks about LibreSSL or pledge(2). Projects can learn from their PR tactics. Capsicum exists for Linux, FreeBSD, DragonflyBSD, so I'm more open to the idea of accepting a patch from the FreeBSD ports tree upstream in my projects' main branches. If I had to guess I'd say they will reimplement something like firejail/systrace as an extension of pledge that doesn't require patching the source and then use it as an opt-out mechanism where you have to whitelist your favorite personal application to have free reign over the machine. Whatever you do, you will inevitably run into the same design considerations that are well travelled and can be inspected in SELinux and more radical capability based kernels. I am of the opinion that security can only work reasonably if mechanisms are opt-out like grsecurity's flag to allow JIT binaries. This allows monitoring as well as knowing your likely open doors for intruders.
