LOL, my first thought was that you were talking about Theo.
I think, we all should be way more cool headed. Email doesn't contain the tone and it is very easy to formulate something in a bad way when exhausted or upset. Some people use very strong words that considering their usual style aren't nearly as strong in reality.
In this case, the great question is, how did such a bad code (according to Jason) land in the code base at all? Don't other people look at it? Do the FreeBSD developers ignore concerns of other fellow developers until it blows up to beyond community communication circles?
Must have: in-kernel WireGuard for NetGate products.
Nice-to-have: a general-purpose FreeBSD kernel WireGuard.
The scope crept, and a piece of code that might have been fit for some purpose (whatever limitations NetGate has for its network stack, like "no jumbo frames", etc) was recast as fit for all purposes.
I guess Colin would have some insight about the process by which a ports-grade kernel module gets put on track for release in the kernel itself.
My take on this is that absolutely no part of the development process that led up to this is Jason's problem. It is not Jason's job to understand or assist or comply with NetGate's product development process; his concern seems to have been, justifiably, exclusively the proposed FreeBSD OS feature. I get the sense that a lot of the friction here comes from pfSense-types thinking that any part of pfSense is everyone's problem.
My question basically is: "How is it possible, the code of such quality was even seriously included in a branch of FreeBSD that would have been released if nobody would step in?" (That is if I understand the whole thing correctly and Jason's assessment is correct.)
This system isn't foolproof, but it generally works very well. There have been discussions about moving to a "mandatory review" model, but there is concern that this might overly slow down development in the context of a volunteer-run project.