I found this very informative as it also compares Linux seccomp and OpenBSD pledge and CloudABI:
https://www.bsdcan.org/2016/schedule/track/Security/661.en.html I can see why you'd want a compartmentalization feature that can be system wide and configured without changing the source, which will one way or another lead to something similar to AppArmor, SELinux, Tomoyo, etc. Too much flexibility is a problem as is being too hard to configure just getting your printer working. What I envision is that if I run mpv to play a video it will have a set of files it may read which are static and known and then the list of files you tell it to play. Then anything else is off limits as is network sockets or any syscall which will allow it to escape its confinement. In the same vein Firefox may not access $HOME outside ~/.mozilla and argv[1...n]. On Linux there are several userspace tools like Firejail that try to make this work seamlessly with profiles, but it is opt-in and often just doesn't work or works too well (fails to keep it restrained). SELinux's mode to deny a program execution makes sense with a curated system like BSD where you can provide the right policies out of the box as long one installs stuff from dports only. If you want to be even safer, you'd make a system without dynlibs and close that loophole too. Matt, what do you have on mind? A better firejail that's built-in and doesn't allow or require user opt-in/opt-out? That's basically SELinux's design minus the implementation details like its liberal use of xattrs which is done to avoid loopholes/problems of AppArmor's file path based filter.
