No, the reality is that getaddrinfo() on most platforms actually follow RFC3484 and prioritize IPv4 over 6to4. (There's a clear distinction in the RFC between 6to4 and other forms of IPv6.) OS X doesn't and uncritically tries IPv6 -- that is, of course, assuming you don't crash into any of the other resolver bugs they introduced in 10.5.
It should be said that if you follow RFC3484 to the letter, 6to4 will be preferred over NAT-ed IPv4. However, that was most likely just an oversight in the standard (the draft revision makes changes to fix that), and most vendors (certainly Microsoft, and most of the major Linux distros, although not glibc upstream yet) has made that change. However, this is moot with regards to OS X, since they don't actually seem to follow RFC3484 in the first place.
You are also wrong in the Airports are the only CPEs that try to enable 6to4 out of the box -- some Linksys models do this, among others. The Airports are, however, most likely the most common. You're also right in that uncritically enabling this is not a good idea; the CPE should at least have done a routability test first.
Finally, you're assuming the statistics here are based only on the User-Agent string on the dualstack hits that come through. They're not -- please read the experiment design more carefully. There is a direct correlation measured between using OS X (as seen in the User-Agent string that fetches the iframe) and inability to fetch the dualstack image. In no way does this result depend on correlation between OS X and 6to4.
/* Steinar */
