I was curious as to what the timeline on the updates to the XML module looks like.

I agree completely the next version with all the enhancements needs to be rock solid.  I love the ideas floating around (ISearchable).  That will be fantastic.

Which leads me to my next question.  Why cant we have an interim release with the most requested/easiest features (xsl params)?  We are only talking a few lines of code here and there should be no problem with backward compatibility.  The hardest part of making these changes is setting up the environment which is what I am trying to avoid.  Not asking for ISearchable or anything just something simple.

I posted some sample code here it is like 10 lines that would help us all out (again xsl params).  Sure it is not optimized but doing so would be trivial.  I would normally be happy to make these changes on my own and use "my" xml module but this makes no since as everybody ends up writing the same code over and over and each upgrade is a PITA.  xsl params should be built into the core module.  There is no good reason for leaving them out.

Sorry to complain and offer little assistance.  Hope you guys can find it in your hearts to throw something together in the meantime.

Stefan Cullmann wrote  Can you please discribe a use case for that?

Sure,  lets say you want to table of employees perhaps you would like to have a link where when you click on an empolyee name it would take you to a detail page.  This page could parse the query string to find the correnct employee in an xml file.  So the link would look like this:
<a href=http://myserver/employeedetail/tabid/1/Default.aspx?employeeid=1>Some Employee</a>

Then the http://myserver/employeedetail/tabid/1/Default.aspx page could have code like this

ASPX
<xsl:for-each select='employee[@employeeid = $employeeid]'>

CODE BEHIND
Dim xslArg As New System.Xml.Xsl.XsltArgumentList

For Each item As String In Request.QueryString.Keys
 xslArg.AddParam(item, String.Empty, Request.QueryString.Item(item))
Next