David:  You state that //command[1] produces a different result than /descendent::command[1].  Isn't // shorthand for /descendent-or-self::command[1].  Semantically aren't these the same thing?  I'm not yet understanding why there is a difference.
Michael: After finally completing an implementation of simultaneous support for XALAN and SAXON, I'm now considering dropping XALAN entirely and using SAXON compatibility mode for 1.0 support.  Anything I should be aware of before making this decision?   
If a template import or include has version 2.0 called within a parent stylesheet of version 1.0, Does SAXON run the imported templates in compatibility mode even though they are marked version 2.0?  I ask because I'm considering the implications of maintaining two sets of library templates, one for each version, when I find the difference between the two to be minimal.  I'd like to discard the original 1.0 version. 
Only differences I've seen so far between XALAN and SAXON are (all with known fixes):
1) saxon:evaluate() doesn't allow variables references so dyn:evaluate("$data//record[@id='1']/field" has been converted to saxon:evaluate('$p1//record[@id='1']/field', $data)
2) //command[1] has been converted to (//command)[1]
3) iterating for-each atomic tokens looses context in the document so set a variable to remember the context within the iterative logic
4) some of the exsl functions are now intrinsically supported by XPath 2.0 so remove the namespace and fix the casting issues