Hi HarryC
Thanks for taking an interest. I don't have a MUX box so I cannot say whether it is a "good" concept. (Nor could I attach a logic probe in order to try to reverse engineer the protocol...

) I guess the bus vs. hub choice boils down to your preference of lots of small smart boxes vs. a larger smart box and lots of stupid sensors... But my stab is actually not at "bus vs. hub", but more towards the "closed vs. open": If you look at the telemetry systems used in the multirotor community, the ones that are used are the ones where the (open) mutlirotor flight controller folks can get access to the API. I would also argue that there is a point to be made that a public telemetry protocol API will increase the availability of sensors and the proliferation of the Weatronic system.
Yes, this in turn might open up yet another can of worms, the reliability of the data. I guess keeping the system closes gives Weatronic an (presumed?) control over the quality of the transmitted data as they might be able to vet the folks whom they grant access--which is something I can somewhat understand as there is a high potential of blaming the R/C system when indeed the data source is to blame (fictitious former customer 'review'/rant: "My Wea system said I was too fast... I pulled back, stalled, and lost my A/C... stupid Wea telemetry.") And loosing a multi-thousand dollar jet is clearly something different than the cost of a "build, crash, repeat" approach followed by oh so many multirotor folks...
Anyways, I guess I am just advocating for giving consumers and informed choice: Hey, you could simply buy our COTS pieces (MUX box, LinkVario, etc.) and get a vetted, working solution... OR you could DIY your own stuff and get what you pay for. And who knows: maybe the solution is simply to use a half-half approach? I.e. make certain messages closed source (for the vetted systems), and publish others as open for everybody. Then you could later use that information in your recorded data to see where your data was coming from (I.e. Weatronic could respond to that fictitious customer by stating that they had no influence on the speed data as that was recorded by an unaffiliated 3rd party.) Or release the API with an NDA and some language for non-commerical use...
But again, I'd argue that Weatronic could sell a lot of systems if one could "simply" send
MAVLink data from your ArduPilot to the ground by simply sending it to the SCA port (be it serial, I2C, SPI, CAN or whatever that SCA port takes...). This combination could provide a really great (and cheap!) solution for a lot of multirotor folks: By a conversion set (which also works with a $50 Turnigy 9XR), and get a reliable --and
LEGAL !! -- long range control and data link. And if the DV4's bluetooth can support it, pipe that data directly into a ground station for the "big picture" (or use your DV4 in listening mode once you upgrade to a BAT)...
Well, at least for now I get temperature and battery voltage for "free"... a more or less perfectly steady 5 V all the way until the LiPo cutoff circuitry is starting to make noises that the input voltage to the switching power supply is dropping

And who knows, maybe once the BAT hits the market Weatronic will be able to free up some resources to make all these great thinks work
Until then: If anybody knows anything about the protocol: please post it here if you can. Thanks!