Use cases for Selectors-API

As for the subject, I was wondering what are the use cases for Selectors
API. Yes, author desperately need a way to get element that match some
constraint inside a document (ie all tables or all p > span.urgent
elements).
But they already have a language to implemented this: XML Path Language +
DOM3 XPath.

Advantages of XMLPath vs Selectors:
- you can use namespaces (you can in selectors too, but not in selectors
api)
- you can return non-node values (ie. the element.matchesSelector
equivalent), either ordered or unordered (possibly faster) node iterators
- you can extend syntax by adding new functions in different namespace (this
is required to support UI pseudo-classes, and actually there are no
facilities to do this)
- once XMLPath model is implemented, also XQuery is easily implemented and
XQuery features are incredible: what about reordering a table without using
HTML5 datalist or java applet? or finding a row in that table based on user
input, without using ctrl+f?
- XMLPath and DOM3 XPath actually are implemented: even FF2 supports
document.evaluate, instead selectors api are included only in the very
latest browser (Opera 10 and FF3.1 AFAIK)

Disadvantages of XMLPath vs Selectors:
- authors must learn a new language
- authors must use XML

For the first issue, I simply answer that many authors don't know the latest
Selectors lev 3 features either and anyway they have to learn the
Selectors-API (yes, they're not difficult, but until they're widely
deployed, the only mean to learn about them are W3C specs, and authors
sometimes don't even know about W3C)
For the second, it would be useful if HTML5 included a way to build an XML
Information Set from a text/html resource. DOM3XPath for example normatively
defines bindings between Information Set elements and DOM interfaces, so
that from any successfully built DOM it is possible to have an XML Infoset.

I'm very curious about what your answer will look like (it seems to me that
I discovered hot water)

Giovanni