Hey, @imp @ktullavik_gmail.com, Could you please take a look at this?

A clean merge of my patch toghether with this fix on top of e8d6b58ef5a4afe0 would
address the problems I'm aware of, and hopefully provide the feature as intended.
There's deeper issues being raised though, seemingly related to each other.

• @jrtc27: is not happy with the structured output [1]
• @jhb: suggests a whole different approach of implementing. If I'm interpreting him right - make a separate execution path that are founded in the internal data structures [1]
• @imp: Libxo seems to be a poor fit for devinfo (I'm not shure if he ment "scrap this whole thing" or if it was just a comment on me raising my dissatisfaction with libxo) [1] And also: "We need a way to export all the data for libxo in one path, not the twisty maze which we've gotten wrong so many times." [2]

I kinda agree with these objections. But I didn't set out to re-imagine devinfo and provide
a different execution path for structured output. I think I like that idea even less than my
already implemented approach of shoe-horning libxo into the existing paths, ugly
as it is.

I'm fine with just scrapping the whole thing. If you want me to have a second (more like
7'th) look at the current approach, I might find the time as the new year settles. The number one
thing I would like to have more feedback on though is if there is concrete objections/suggestions
to the structured output. Please show how you'd want it.

This whole thing is getting embarrasing. If I knew it would create this much problems,
regressions, churn, and take so much attention from real devs, I'd just leave it in the
no_one_will_ever_know directory.

[1] https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=291511
[2] https://reviews.freebsd.org/D54196

For the confused reader (including myself):
My patch to add libxo supprt to devinfo was added in c759aca606cee8352
and then later reverted in 43b07bdbc5d24febc7a
and then @kgalazka revived this thread with a concrete fix, but there is more to it