Or someone had permission, but the entity who issued that went silently into the night, and those IPs only recently went back into the pool, and these exist until the person has renumbered out.

PPP for IPv6 only will let you define link-layer addresses in the initial connection.  That's the extend of IPCPv6's direct support.  From there you have to define statics, or use RA to deliver the appropriate prefix information to clients which either don't require statics, or can't configure statics.

I set up a new tunnel in Seattle.  The create tunnel screen recommended Ashburn, VA as the PoP.  Why?  (My guess: it goes by where you are viewing from rather than the endpoint IP.)

Correct.  It's based on which instance of the anycasted locator you're getting routed to.

I pinged the Seattle PoP and two Freemont PoPs, and the Fremont PoPs were consistently slightly (34.7ms vs 35.7ms) faster, even though farther away.  Why?

Geographical location doesn't always reflect the network path.  A traceroute should help shed some light as to where the traffic is going.  Fremont, being in the SF Bay Area will tend to have, in general, better connectivity than a secondary network market as Seattle tends to be.

So I created the tunnel with the Seattle PoP (figuring an earthquake in Fremont shouldn't take Seattle office offline).  Pinging the Denver office via IP6 was 80ms.  Pinging Denver office via openvpn was 37.3.  So I set up another 6in4 tunnel between Seattle and Denver, with a ping6 time of 35.9.   I'm guessing without the direct tunnel, the ping6 time includes a 35ms hop between each endpoint and its PoP.  Pings to google.com are fast (37ms) from either location.

Right.  Traffic times will always also include the underlying v4 path to the tunnel server.  Unfortunately tunnels don't act like wormholes.

Sixxs doesn't do BGP peering since they don't do their own routing.

Since tunnels are stateless, there's no up/down/etc.  On this side it's configured to move traffic regardless of how recently you last did.  If you're got a device performing NAT or a stateful firewall that's handling the tunnel traffic in any way, you'll either need to keep some sort of outbound traffic keep-alive (periodic ping), or insert a specific rule to permit the tunnel traffic, otherwise the outbound state will expire on your side, and inbound traffic won't have anything set to let it back inside.

6in4 tunnels are actually stateless, and the TC should still try and do its job even with an 'error'.  What firmware release are you on?  7.6.3 seems to have some issues in the IPv6 department, so in those cases, you may want to try 7.6.1 and see if this helps improve your situation.

As to updating the endpoint, there are several options, but the best would likely be to use a ddns client application, schedule it regularly on a system behind the TC and set it up as noted here: http://www.tunnelbroker.net/forums/index.php?topic=1994.0.  You'd want to use the auto-detect format.

Tunnels are back to Seattle now.

Seattle tunnels have been rehomed to Denver until the Seattle tunnel server is back in operation.  You shouldn't have to do anything on your side to adjust for this change.

The Advanced tab on the tunnel information page.

There are several threads on the Apple support forums about this topic, and there's been no reply back from them to any of the users seeing this issue.  Everyone there has had success just going back to 7.6.1.

https://www.tunnelbroker.net/forums/index.php?topic=2782.0

We're not remapping TTL.  Were your TTLs always 3600?  If they were higher previously, those timers have to expire before the new ones will be checked.

I don't see any dynamic DNS update information associated with any of your tunnels.

To continue the weirdness, I tried updating a 4th gen AEBS with native, non-tunnel, IPv6.  After going to 7.6.3, no IPv6 love on the internal network.

So either there's something funky with the update, or some setting hiding is causing issues, or I just have the absolute worst luck in the world.  At least with the 4th gen, the delegated prefix doesn't zero out.

Still nothing planned for this.  Except in specialized networks, the gains of multicast over unicast for that kind of application is extremely limited.