This looks reasonable. Please see comments for some small items to check.

This looks reasonable, but let's wait for some more feedback from the others.

I like it. Please land the new header and kernel fixes separately in case reversal is needed.

Looks like a good patch. Could you add unit tests that make sure the constraint handles actually trigger on error?
Please mention in the commit message that this also documents bsearch_b.

Approved for commit.
Do you wish to have these changes merged into stable/15? If yes, consider adding an MFC after tag. I recommend a wait of 1 month for new features, 1 week for bug fixes.
Same goes for your other C23 changes. You can MFC even if you did not add the relevant tag, but you'll only get a reminder if the tag is present.
If you wish to add "MFC after", just do it on commit. You do not need to ask for approval again.

Please add the desired commit messages for reference.

Nice work. Some feedback is attached.

For example, the build-option survey is not trying to solve an equation but test for combinations of build-options that break the build when combined together.

In D58700#1347628, @dteske wrote:

On the proposed commit messages, I think Robert (@fuz) will agree, I think we would put:

Reviewed by: dteske, fuz
Approved by: dteske (mentor), fuz (mentor)

Or if Robert wants, co-mentor.

Looking good here.

I'm relieved, I never managed to find time to get one.

In D58699#1347230, @kfv wrote:

@fuz: I don't have access to the doc repository. Am I expected to handle this myself, or do we need a doc committer to take care of it on our behalf?

Commit message looks workable.

Please post the commit message you plan to use so I can then give approval for commit.

In D58688#1346727, @kib wrote:

In D58688#1346717, @inquire_JohnEricson.me wrote:

@fuz You may be interested in https://github.com/catern/rsyscall, which I referenced in my original 2022 freebsd-arch email linked in the patch description. It adopts the same philosophy.

We have ptrace({PT_SC_REMOTE). Allowing remote syscalls as a generic facility without attaching to the target as debugger is IMO not acceptable.

In D58688#1346727, @kib wrote:

In D58688#1346717, @inquire_JohnEricson.me wrote:

@fuz You may be interested in https://github.com/catern/rsyscall, which I referenced in my original 2022 freebsd-arch email linked in the patch description. It adopts the same philosophy.

We have ptrace({PT_SC_REMOTE). Allowing remote syscalls as a generic facility without attaching to the target as debugger is IMO not acceptable.

It sounds like this could perhaps be simplified by having a pdsyscall system call that executes a system call on the given process descriptor. Then all manipulations on the zygote process just become normal system calls carried out through pdsyscall and activating a process image becomes a call to execve() or similar through pdsyscall. In particular this avoids having to add new stuff every time we come up with something new that we want to set up before sending off the new process.

Looks reasonable.