I only do bsd stuff in those brief moments where either someone shows up actively to help, as you d id, or or when I simply have too much time on my hands, as now. Normally I don't really look at it, I will fire up an openbsd and maybe a freebsd vm and see if latest changes work, but as you could see this time, I'd been using old vms and in the meantime lots of stuff had been changed in newer bsds.
My attitude towards the bsds is a bit different than it used to be, in the past, I got pretty good access, I had some people actively involved giving me ssh access (ssh access speeds my development time by at least 100x, literally), and actually, on the readme on github, I actually stated flat out that I would not touch a bsd problem or issue without direct ssh access because it takes too long, and helps far too few people for those man hours.
I made an exception this time, which you basically saved by doing a lot of real hardware installs, because I was in the middle of a big refactor anyway, and thought I'd update the bsd stuff. But I've found trying to get useful or usable debugging data from bsd guys is... very time consuming, to put it mildly. Way too time consuming for me to volunteer to do it routinely. Basically, my general rule of thumb for hard, non trivial issues, is: no debugger data when requested, no support, period, since otherwise it's my time being eaten, and, for systems I don't run, no ssh access, no support, since it's my time being chomped away for something I don't even use.
Luckily the inxi debugger is so rich that usually I can figure out even super obscure issues like failed raspberry pi device detections without direct access to the system, but the actual reason I got ARM stuff working was a guy gave me ssh access for a few months to a few devices, which was smart, that's how you get your stuff supported, real metal installs, no vms, the only way to go, ssh, massive time saver. But that's with linux, which has easily at minimum, an order of magnitude more data available, and readily and predictably available, in consistent logical structures, than the BSDs have. They are, imo, really shooting themselves in the foot by making their reporting tools break, be inconsistent distro to distro, or as they like to put it, os to os, it makes supporting them far too hard.
But with this said, I prefer one of two things happen for inxi: 1. it has decent bsd support, until they break it by breaking their data syntaxes, 2. no bsd support at all, and I just fly the white flag, and surrender. I was this close to giving up this time, and removing all the bsd logic, but decided to give it one more go around since perl inxi and refactored perl inxi are MUCH easier to work on than ever before, and getting easier all the time. but when, not if, they break various data formats again, I'm not really obligated to fix it rapidly, I mean, sure, yes, I can fix broken data format parsing in iinxi for bsds every time they do a new release, or I can spend the time doing other stuff, and they can stop breaking their data output, or, even better, design better tools that don't rely on such fragile data in the first place. They have a start in sysctl but it's kind of sparse, gpart is actually good, so they have some decent reliable tools, but not very many.
I used to really like the bsds, but I think a few too many years chasing their random changes and breaks cured me of that, now the only one I'd personally find useful is openbsd.
I think basically all the bsd logic was done mainly in 2 big bunches, the original one, and this last one, now. I've run freebsd servers for years, but I never had wheel group access to them, so the data I could get was limited, but that's why freebsd stuff tended to work, more or less, I could ssh into a box and test it. That's why zfs raid stuff works too. But each time I touch bsd stuff after being non active in it for a few years, I'm truly dismayed by just how much stuff has broken, I mean, it's kind of terrifying. This time around, I could see many of the changes were for the better, but some were just plain silly, like openbsd wrapping pcidump -v output so the entire output would only be like 40 columns wide, I mean, why? that's just silly, and makes it a lot harder to parse the data.