I see this as being a LOT more work to implement, test and debug than simply accepting a number of parameters that have default values for them?  The XML allows you to specify a number of orderIDs - again, accept a varchar(8000) param as a CSV list of order IDs and use a simple UDF to split them into a table against which you can join...  The default values for all parameters can be NULL - if it is NULL then it is ignored (by appropriate code in the where clause).  Apart from that, I tend to have followed the same approach for many of the filtering screens in our application. 

An optimisation can be made if you know that certain parameters are likely to appear by coding different branches of code in the stored proc so that the where clauses in the statements can make use of indices (no OR statements on the parameters that are always used in a particular branch).

I haven't done any performance comparison of CSV string splitting VS XML, but I imagine the overhead of invoking the XML processor, as well as the annoyance of building the XML client-side (or even worse, testing in Query Analyser) means I'll be sticking to CSV lists (where needed) and default values of NULL for parameters unless convinced otherwise...

I will be happily proven wrong - so long as it's done nicely