This sounds like one of the use cases for maps, which are introduced in XPath 3.1. A function can return multiple results in a map, and the map can either be passed to another function as a single argument value, or its components can be passed in multiple arguments:

declare function f() {
  map{ x:23, y:34 }
}

declare function g($x, $y) {
  ...
}

let $f := f()
return g($f?x, $f?y)

(In reply to Michael Kay from comment #1)
> This sounds like one of the use cases for maps, which are introduced in
> XPath 3.1. A function can return multiple results in a map, and the map can
> either be passed to another function as a single argument value, or its
> components can be passed in multiple arguments:
> 
> declare function f() {
>   map{ x:23, y:34 }
> }
> 
> declare function g($x, $y) {
>   ...
> }
> 
> let $f := f()
> return g($f?x, $f?y)

Yes, indeed it does sounds like it but this solution only meets the requirements halfway. The solution forces the use of a variable ( $f in this case) and it doesn't allow functioncalls to be nested. 

The result of function f() still has to be brought back (serialized) to the program ( $f), there being splitup in its origional elements ($f?x and $f?y) and individually being fed to function: g#2. This all could be done in the background if function f()'s result could be interpreted as a sequence of arguments within the call to function g#2.

I realize that this would have a significant impact on the internal xquery-design and I probably wouldn't have mentioned it if it hadn't, to my opinion, so much in common with the apply-request: https://www.w3.org/Bugs/Public/show_bug.cgi?id=26585

>This all could be done in the background if function f()'s result could be interpreted as a sequence of arguments within the call to function g#2.

That is very difficult to achieve given that the number of arguments (arity) in the function call to g is used when deciding which function is being called.

(In reply to Michael Kay from comment #3)
> >This all could be done in the background if function f()'s result could be interpreted as a sequence of arguments within the call to function g#2.
> 
> That is very difficult to achieve given that the number of arguments (arity)
> in the function call to g is used when deciding which function is being
> called.

Yes, that will be an issue that has to be tackled then ;-). But hé, if it is interesting enough for the xquery-language ...

Just came back from my run and I kept wandering what the actual fun is of the arity of a function being part of its identification. Is that more interesting than being able to nest functioncall to functions with more than one return value?

An option could be, so both features could be implemented besides eache other, to be able to overrule the arity calculated from the argumentlistsize with the #<integer> notation in case of these nested functioncalls, f.e. g#2(f())

Just something that popped up while running.

Making things "fun" and "interesting" are not criteria that the WG usually uses to justify its design decisions. Perhaps they should be.

I'm confident the WG will use the right criteria and I can reconcile myself in whatever will be decided.

Many thanks for your suggestion.  After discussion, the WG decided at its meeting on 2014-10-27 that is would not be feasible at this stage of development to add this capability to XQuery.  Consequently, with regrets, we must reject your suggested enhancement.  If you accept this decision, please mark this bug as CLOSED.