OpenBSD system-call-origin verification

Yes of course: some hobbyists have fun implementing libraries with insanely small footprints, only to be used in systems several orders of magnitude bigger. It's like a sport.

You should actually look at some of these libraries and corresponding operating systems, they tend to give examples of the sort of real hardware they target.

Most code ever written won't compile or run on modern Unix systems, short of emulation, and the dialects they're written in fundamentally won't work well on Unix. You can't really use certain Forth dialects, as they implement hard drives as an array of sectors that the program has arbitrary access to. MS-DOS C dialects assume segmented pointers. VMS C has its own system calls that makes porting any non-trivial program challenging. Same thing with Windows C. Many BASICs assume you can PEEK and POKE certain memory locations for certain effects. You can't run most assembly languages or machine language; 68000 assembly written for OpenBSD won't run on any modern version, and never ran on any non-68K OpenBSD. You can run any language or program on any sufficiently large system with enough layers of indirection, but virtually all non-trivial code not written for Unix systems is going to make enough assumptions about how things work that Unix disagrees with to require serious emulation or virtualization to work without code changes.

The boundary of "your programming language of choice must not be one we disapprove of" was first willfully crossed when memory protection and filesystems were added.

And you say you're not "complaining", but you've chosen to characterize the "eternal OpenBSD quest" in a biased way that sounds a lot like a complaint; the goal is to "increase resilience against bugs", by many tactics, not just those which some rare programmers might find complicating things.