Yeah if you read RFC-3484, you'll see that the "label(S)==label(D)" step is way down on the list, and the "prefer outbound interface IP" is ahead of it, so it never gets to that step in the case of multi-interface machines. I tried to note that in my last message.
The prefixpolicy RFC-3484 source address selection stuff only seems to apply when you have multiple IPv6 addresses on the same interface. When everything else in the list is a tie, then you can preference one source address over another using prefixpolicy.
The only surefire way to do it is to actually specify which source address to use. A lot of software supports this, but not all. I'm not sure if theres any way to make IE or FF use a particular source IP. But I'd think most system services could be manually bound to use a particular address for outbound initiated connections.
Anyway, on my IPv6 router, it behaves the same way. If I want it to use my LAN interface address, I have to tell the particular piece of software to use the particular interface or address. This always overrides prefixpolicy, etc.
Actually, I only have one NIC interface (enabled) on this machine, but if you mean multiple interfaces in the sense of virtual and pseudo interfaces along with the NIC, then I see your point. And, oh yeah (of course), I will be specifying which address(es) to bind listening sockets to in my services, so source address selection shouldn't be an issue for my listening services.
My point about Windows implementation of RFC 3484 was that, regardless of the ordering of the steps in the source address selection algorithm, the administrative override should take precedence. Anyway...
HOWEVER--I THINK I HAVE IT FIXED! Or at least working the way I want it to. Here's what I ended up with (and don't tell me I'm wrong cuz I'm not listening

).
1. I added a IPv6 Default Gateway Route from the NIC to the remote tunnel endpoint IPv6 address.
2. I deleted the local tunnel endpoint IPv6 address from the tunnel interface.
Now, I can ping out, the outbound ping source address defaults to the NIC Routed /64 address, and remote sites detect my (source) address as the Routed /64 address. Here's what the route table looks like:
netsh interface ipv6 show route
Publish Type Met Prefix Idx Gateway/Interface Name
------- -------- --- ------------------------ --- ------------------------
Yes Manual 1 ::/0 10 2001:470:1f04:a85::1
Yes Manual 1 ::/0 15 2001:470:1f04:a85::1
No Manual 0 ::1/128 1 Loopback Pseudo-Interface 1
No Manual 0 2001:470:1f04:a85::/64 15 IP6Tunnel
No Manual 0 2001:470:1f05:a85::/64 10 Local Area Connection
No Manual 0 2001:470:1f05:a85::6/128 10 Local Area Connection
No Manual 0 fe80::/64 10 Local Area Connection
No Manual 0 fe80::/64 15 IP6Tunnel
No Manual 0 fe80::5d1:3ef0:29cf:740d/128 10 Local Area Connection
No Manual 0 fe80::4571:e519:fffa:2d7f/128 15 IP6Tunnel
No Manual 0 ff00::/8 1 Loopback Pseudo-Interface 1
No Manual 0 ff00::/8 15 IP6Tunnel
No Manual 0 ff00::/8 10 Local Area Connection
And, here's the prefix policy table. Note that I did update it, but it never made a difference until I made the changes in the route table and interface addresses.
netsh interface ipv6 show prefixpolicies
Querying active state...
Precedence Label Prefix
---------- ----- -----------
50 0 ::1/128
40 1 ::/0
30 2 2002::/16
20 3 ::/96
10 4 ::ffff:0:0/96
40 1 2001::/16
I hope that's the end of this issue as I need to start searching for services software that supports IPv6 better than the stuff that comes with Win2K and Windows Server 2003. Oh, and an SMTP server for Windows Server 2008.
I'll reboot and make sure this is all still working afterward. If so, I'll post a final confirmation that this is solved.
Thanks for your help and input.