Suddenly, it is in the best interest of other developers to include QN support. We've reached critical mass.
That's the problem there... I agree with the idea, but no one has the oomph to push such a standard onto everyone. It'll take way more than a couple of companies using it. Plenty of companies will not use it just because they didn't invent it. Mostly, they'll just ignore it. There've been a number of such attempts to create these types of standards, and they just don't go anywhere because the market is way too broad ('automation' covers everything that could be automated, from lighting to sprinklers to A/V components to shades and so forth) to get any sort of consensus going.
And partly it's because, as we've both said, beyond just adopting the protocol, they must adapt to the protocol and meet certain standards that the protocol requires, such as consistently working in certain ways and exposing certain features. That's almost never going to happen. They'll build whatever they build and then they stick a serial port on it and provide a half working protocol, and that'll be that, because they often don't see automation as a key part of their market, just a small adjunct to it, not worth taking on any significant expense.
If you look at the breadth of companies you'd have to get to buy into such a thing, it would be Sony, Philips, Lutron, Aprilaire, Denon, Panasonic, Zen-Sys, Draper, and on and on. They are so disparate in their markets that they might as well be in different universes.
That's not to say it will never happen. I just don't expect it to happen in my lifetime, unfortunately. And that's not to say that people should push for it, since it won't happen any faster if people don't. But you should be prepared for a job that would make Sysiphus' look easy.
I'm not sure that ethernet is the best solution for the backbone in a broad acceptance of automation. It just wasn't designed to be self maintaining, and the danger of not failure of the network but failure of name resolution services, which will bring everything to a halt, is non-trivial in a system that can expect to receive little or no preventive maintenance by the customer, but which is constantly directly accessed and messed with the customer.
Maybe it requires a separate wired sub-net for the automaiton system or something like that, I don't know. But the single biggest problem we have is that the customer says X isn't working. We get the logs, and it's a name resolution problem, so client Y cannot find server Z. DNS and DHCP are moldy old technologies for the most part, designed for big machines managed by profesional people who know what they are doing and who do regular maintenance of the system.
I've had problems myself, where I removed a node from my Windows domain, but the DNS entry remained, and therefore machines referencing the old name didnt' get any errors (so that I see this and could fix them), but continued to reference this now out of date entry, which resolves to the same (fixed) address as the new machine that replaced it. Later on, I change the fixed address of this new machine, and now suddenly things stop working because the clients still trying to resolve that old name are getting a bogus address.
These types of things, to me, are why I think that a more dedicated network for the automation system would be optimal for a broad acceptance of automation into the homes of the great unwashed masses. And it's not just automaiton of course. Lots of devices are being networked, so everyone has a stake in getting this type of thing dealt with better. It's not as big a deal in the high end, where the customer always has a installer to call and get it fixed. But in the world where the only recourse of the customer is to call customer service in at Best Buy, they may die of old age before they get it fixed.