The thing is that OpenBSD has his own libc from their Xenocara project.
So it is not out-of-the-box like other libc systems.
I don't think that it is it. I think it is something with the startup code, probably related to the changeover to LLVM (or later revisions of the target after the initial change), and/or maybe something they needed for their security work. This is why I pointed to the ELF ident source file.
If you pass wrong structs (to e.g. statfs and stat, the most common libc issues), you see it in strace, and you get a nice traceback in gdb, and that doesn't seem to be the case. Renumbering IOCTLs is another common one.
If binaries from 7.4 fail in the same way on 7.5 as 7.5 native ones when you update the version in the ELF ident in that file on 7.4 to the number that native 7.5 binaries have (elfdump -n), it means that the normal 7.4 binaries run in an emulation (the so called COMPAT library sets).
This has happened before, FreeBSD binaries relied on COMPAT versions to, and in fact 3.2.2 doesn't not run natively beyond 11 or. (but fixes does run native on 13 and 14)
I think making the effort to make fpc fully compatible with OpenBSD is worth it.
Without a maintainer, it will be hard for a platform in so much flux. Anyway, if no one of you can/wants to do it, try to bundle information in bugreports, preferably in a very reproducible way. A future maintainer might take that as input.