This is a consolidation of some views in the www-ql@w3.org mailing list on the 
issue.

Current spec only allows atomic values to be returned in the last step of 
XPath. And it is a compromise between two extremes, i.e.:

1. No atomic value to be returned in XPath
People supporting this want to preserve the node selection nature of the '/' 
operator and XPath. And prefer to use FLWR expression to work on atomic values.

However, even we go this way, we still cannot prevent the general iterator 
semantic, people can still construct expr like:
<a/> / <b/>,
let $a = any-node-expr1, $b = any-node-expr2 return $a/$b

2. Atomic values can be returned in all the steps in XPath
This would make '/' a general iterator, or mapping operator.
Personally I strongly support this semantic. Because it makes the semantic 
of '/' very simple and clean.

If we introduce a 'foreach' expression under XQuery like in XSLT,
then 'expr1/expr2' would be equivelent to 'foreach (expr1) return expr2'.
Then '/' becomes an abbreviation, just like '//' is the abbreviation of
'/descendant-or-self::node()/'. Even we don't introduce the 'foreach' 
expression in this version, we can still define the concept in the Semantic 
spec.

Allowing '/' to be iterator, can help construct some compact expressions, like:

concat(min(//*/local-name()), '-', max(//*/local-name()))
rather than
concat(min(for $n in //* return local-name($n)), '-', max(for $n in //*
return local-name($n))

Generally, the most common use case would be using '/' as a mapping operator, 
which is available in many funcational languages that applies a function unto a 
sequence of values.

Since we cannot eliminate the mapping semantic of '/' anywhere, why not accept 
it.

Personally I would strongly suggest either no atomic values to returned in
path expression or atomic values to returned in any step of the path.
The middle way is not a good choice. It makes the semantic and implementation 
more complicated and can cause a lot of confusion.