In meeting 427 there was some discussion about the equivalence of axes and functions, and I was actioned (A-427-23) to summarize the discussion in a new Bugzilla entry so that it could be considered as a basis for enhancements for a future release. The discussion at meeting 427 is minuted at http://lists.w3.org/Archives/Member/w3c-xsl-query/2010Feb/0189.html (member-only link): see agendum J4.2.5.

First, we observe that the semantics of axes could be defined in terms of functions of the form fn:child(node()) -> node()* (for some of the axes, the cardinality of the return type can be given more precisely than this). Making the axes available explicitly as functions would have a number of benefits:

(a) semantic clarity: it makes it clear that there's nothing magic about the semantics of axes

(b) it would make them available for use as function items that could be passed as parameters to higher-order functions or returned by higher-order functions.

(c) function composition involving axes would no longer require use of the "/" operator, which has reordering side-effects. For example one could write map(child#1, descendant(.)) to get the children of the descendants without reordering. Using function composition rather than path syntax might also be an attractive option for code generators.

Conversely the path notation a/b/c is attractive from a usability point of view in comparison with map(c, map(b, a)). It is already possible to use a function call as a step in a path expression of the form 

customer/f:cust-orders(.)/product-code/f:product-for-code(.)/price

However, the asymmetry here between built-in navigational functions (the 13 axes) and user-defined navigational functions is striking. Allowing axis notation (including node tests) for user-defined navigational steps would add symmetry. The above could then be written

customer/f:cust-orders::*/product-code/f:product-for-code::*/price

Here I have used a node-test of "*", but of course any node test could be used.