Which hardware and OS are you describing? Clearly the blog post illustrated some examples where switching to v6 was not happening, so it seems to contradict your comment right off the bat. There are many implementations of dual-stack IPv4/v6. In fact, they are more divergent than IPv4 implementations, because the latter often derives from the BSD-RENO codebase, while IPv6 was introduced after Linux became King, so Microsoft, Apple, and Linux (and lots of router/firewall vendors) have ostensibly developed IPv6 stacks separately, some being more open than others. They're not all going to work the same way with fallbacks/failovers.
> Which hardware and OS are you describing?
This is how it's supposed to work on all OSes; on any recent BSD (excepting perhaps Apple?) or Linux setup, it should work this way.
> Clearly the blog post illustrated some examples where switching to v6 was not happening
In those situations it was for connecting to services that do not advertise a AAAA record.
https://www.rfc-editor.org/rfc/rfc5220.txt
I'm not sure why you specified "if a host has no route to the address", because that's a very specific and transient failure. Furthermore, the dual-stack handling necessarily happens in the application, so this is not an OS or kernel-level decision, it will be subject to each individual app's behavior: https://issues.apache.org/jira/browse/SERF-190
As you can see from RFC5220, IPv6 is preferred over IPv4, unless an option is set to swap those around. Of course, certain configurations can confound this preference order, such as ULA IPv6.
"No route to host", as should be obvious, is only one of many errors that could prevent an app from establishing an IPv6 connection. It would seem that they should handle most failures as an occasion to fall back to IPv4, unless configured not to.
