The "sequential focus navigation starting point" in WebKit and Chromium

Both from a user perspective and from a technical perspective, I like the way Chromium is formalizing the "sequential focus navigation starting point".

A few highlights of this change:

If a navigation to a url with fragment identifier happened, an element pointed by the fragment is set as sequential focus navigation starting point.

In other words, anchor links like #skip_to_main will now work for keyboard users, without any JavaScript. We've only been waiting for this since 1990!

If the element pointed by sequential focus navigation starting point is removed from the document tree, a point where there was the element at would be the starting point.

This is good for accessibility in modern web sites, such as single-page apps. We'll first need to see some follow-on improvements in browsers and assistive technologies, but eventually this might allow web authors to simplify focus management, as DOM elements are removed and changed.

Implementation: Sequential focus navigation starting point is represented as a Range object, and it is owned by a Document.

This is the technically elegant part. It builds on existing patterns, to achieve something new.

Now I have a few questions for the community. The behavior is already looking good for users, so these questions are mainly geared toward supporting web authors.

1. There's a standard and widely supported Range object. What's the interface to access this new special Range? Maybe as a property of the Document?
2. The related WebKit ticket points out that Gecko (Firefox) and Trident (Internet Explorer) already have their own implementations. Can this interface be standardized across browsers, or is it too late for that?
3. As the Chromium issue points out, there are several kinds of scripted behaviors and user behaviors which cause the Sequential Focus Navigation Starting Point to occur. Although not mentioned specifically, presumably the point could change any number of times before any DOM element gets focus. Given that these various behaviors all lead to a single thing happening from a user perspective, could we fire a device-independent JavaScript events? It would be a mouthful -- "onSequentialFocusNavigationStartingPointChange" (?!?) -- but you get the idea.
4. Would it make sense for this Range object to be the relatedTarget of blur events?

Finally, I have a couple of more questions that are geared toward making life easier for developers of browsers and assistive technologies.

5. Is there a consistent behavior in browsers for caret navigation?
6. What are the use cases for mobile browsers?
7. Similar to the JavaScript event questions -- can there be a related event in accessibility APIs? Screen readers have tried to compensate for browser differences, but this could lead to more consistency in the future.