p:xslt and p:xslt2 (and "p:any-xslt"?)

Coming from a background of using Ant to manage XML-processing pipelines 
(DITA Open Toolkit, if people care) I am somewhat confused over the exact 
intent of the separation of p:xslt and p:xslt2.

For comparison, Ant has an <xslt> task which invokes whatever (usually 
JAXP) external XSLT processor happens to be installed on my system.  It 
might be XSLT 1.0 or it might be XSLT 2.0.  That may seem underspecified 
and dangerous compared to XProc, but I use that fact to my advantage: 
while DITA-OT core stylesheets are all XSLT 1.0 instances, I import XSLT 
2.0 snippets into them for custom processing, and run the whole pipeline 
with an XSLT 2.0 processor, letting it run in backwards-compatible mode 
for the core 1.0 bits.

I don't know how I'd do that with XProc because I am unclear about the 
precise rules of conformance.  My questions about the p:xslt and p:xslt2 
steps, which I don't think are addressed in the 20 September 2007 draft:

- If I run a p:xslt step, and the XProc implementation implements p:xslt 
by calling an external XSLT 1.0 processor like libxslt or Xalan, do I get 
a static or dynamic error if the external XSLT processor is absent?  (I 
would assume dynamic.  I think that the draft says this, but I want to 
check my understanding.)
- If I run a p:xslt step using an XSLT 2.0 stylesheet (or an XSLT 1.0 
stylesheet that imports 2.0 snippets), am I guaranteed that I will get an 
XSLT 1.0 processor running in forwards-compatible mode (a la XSLT 1.0 
spec)?  (In other words, is it non-conformant for an XProc implementation 
to delegate processing to an external processor like JAXP if the latter is 
at risk of running an XSLT 2.0 processor if that's the only XSLT processor 
the user has installed?)
- If I run a p:xslt2 step and the XProc implementation dosn't implement 
p:xslt2, do I get a static or dynamic error?  (I would assume static.  I 
think that the draft says this, but I want to check my understanding.)
- If I run a p:xslt2 step, and the XProc implementation implements p:xslt2 
by delegating to an external XSLT processor such as Saxon 8, do I get a 
static or dynamic error if the external XSLT processor is absent?  (I 
would assume dynamic.)
- I want to define a step that invokes the "best available" XSLT 
processor.  Would it make sense to implement that as a combination of 
p:step-available("p:xslt2") (to fend off static errors) and p:try/p:catch 
(to recover from dynamic errors due to absent processors)?  Given XSLT's 
very good cross-version compatibility, would such a step be useful enough 
to enter the standard library?

-- 
Deborah Pickett
Information Architect, Moldflow Corporation, Melbourne
Deborah_Pickett@moldflow.com