Actually, XQL is significantly more than rich path expressions, and I think it would be very useful to have a rich query language that can do joins, transformations, ordering, aggregate functions, etc. However, I believe there is also a need for a simple query language that is easily implemented in a wide variety of settings, and which scales well for efficient access to very large repositories - this is what XQL was designed for. Peter Fankhauser of the GMD in Darmstadt has suggested a means of extending XQL to support joins. I intend to add a discussion of that here in the near future. I would be open to adding an extension for joins as an optional feature in XQL, provided we can achieve consensus on this in the XQL Mailing List.
Transformations are a more complicated issue.
XQL has been criticized for being too simple, and it has also been criticized for being too complex. The minimal implementation set of XQL is intended to be simple, easy to implement, and easily optimizable. Nevertheless, some minimalists have argued that even the minimal implementation set of XQL is too complex. XQL was designed using a large sandbox of documents, including traditional XML and SGML documents, HTML documents, and data-oriented XML documents, and the features found in XQL reflect the queries that we found useful for the documents we studied. The best implementation depends a great deal on what you are doing, eg. whether you are dealing with single documents in RAM or large document repositories.