> Basically, namespaces and XPath don't sit too well together

It works fine when you understand how to use it properly.

The only real problem is that XPath relied on prefixes retrieved from 
some unspecified environment (depending on the context/tool in which the 
XPath is being executed). That's a bit less verbose than using an 
"expanded qualified name" like {http://my_namespace}foo, or requiring 
that the namespace bindings be specified via some syntax in the XPath 
string. But it does mean that an XPath is partly defined by that 
context. (Then again, XPaths which use variables also need a context, as 
do those which use some of the functions, so this is just the most 
obvious -- and most unnecessary -- instance thereof.)

It is possible to write a portable namespace-aware XPath that doesn't 
rely on prefixes (via some ugly predicate hacks)... but it really should 
be easier to do so. Oh well. 20:20 hindsight; maybe XPath 3.0 will 
finally reconsider that point.

By the way: The namespaces shown in the original example are not 
considered acceptable by today's standards. Namespace names should be 
fully-qualified ("absolute") URI References. Yes, the original namespace 
spec was fuzzy about that, and many tools won't enforce this... but 
after much painful debate, the W3C agreed that the concept of a 
"relative namespace" really didn't make any sense no matter how you 
sliced it. Tim Berners-Lee reserves the right to reintroduce that idea 
if and when the Semantic Web effort comes up with a way to make those 
meaningful... but until then, you really should make sure all your 
namespace names follow the official absolute-URI-reference syntax.