6to4 addresses are global, even the ifconfig ipv6 address listing
in your output indicates this
the source address selection algorithm specified by the RFCs makes
a distinction between scoping types (global, site local, etc.) but
not between different types of global addresses such as 6to4 ones
You can see the exact source address selection algorithm, which is
an implementation of what the RFCs require, in net/ipv6/addrconf.c
function ipv6_dev_get_saddr(). It walks the specified device (usually
the one for which the packet has been routed to), and picks the first
address on the device which matches the scope of the destination IPV6
address for the route.
Sorry, I really don't see this as a bug. It might be instructive for
you to take this up on the netdev@vger.kernel.org mailing list so that
it can be discussed with the USAGI project and other IPV6 experts more
thoroughly.

I cannot disagree more.
First of all it is a pity you hasn't refer to specific RFC.
Second: there is something in source address selection which prevents
connection establishemnt and there is no workaround (I mentioned I tried to
add routes with explicit src address and it didn't work and this alone may
justify treating this as a bug).
Now some pointers:
RFC3056 section 2.1 and discussion of point 3 in section 5.2. Please also
note that this RFC treats native IPv6 and 6to4 networks as independent routing
domains and this alone will cause routing failures if address from one
domain is used in the other.
RFC3484 section 5 rule 6 (which will alone choose 6to4 source for 6to4
destination and native source for native destination in default configuration)
and rule 8 which says: Use longest matching prefix.
Reopening.

I reiterate my request for you to bring this up on the Linux network
developer mailing list so that it can be discussed with other Linux
IPV6 experts. I'd really appreciate you doing that, and it would
accelerate this bug being resolved.
Discussing the patch here is a dead end because the USAGI and upstream
folks need to be involved before we can put it into our tree.
SO this is in needinfo until the netdev mailing list thread is started.
Thanks a lot.

Judging from quick look in a code it is not fixed.
I filed bug on kernel for this (http://bugzilla.kernel.org/show_bug.cgi?id=5200)
to push it upstream and that all I can do as I don't have resources to push
discussion on kernel mailing list.
The bug in kernel bugzilla is still NEW for quite some time.

The current upstream 2.6.x kernel does have the RFC3484 source address
resolution fixes, it's in Linus's current GIT tree.
How likely it is that this will propagate into the FC4 kernel, I have
no idea.

This is a mass-update to all currently open kernel bugs.
A new kernel update has been released (Version: 2.6.15-1.1830_FC4)
based upon a new upstream kernel release.
Please retest against this new kernel, as a large number of patches
go into each upstream release, possibly including changes that
may address this problem.
This bug has been placed in NEEDINFO_REPORTER state.
Due to the large volume of inactive bugs in bugzilla, if this bug is
still in this state in two weeks time, it will be closed.
Should this bug still be relevant after this period, the reporter
can reopen the bug at any time. Any other users on the Cc: list
of this bug can request that the bug be reopened by adding a
comment to the bug.
If this bug is a problem preventing you from installing the
release this version is filed against, please see bug 169613.
Thank you.