ResetableIterator, I'd certainly call it a flaw. It kind of defeats the purpose of having those nice abstract classes and interfaces in the first place.
As for returning
XPathNodeIterator instances from your extension functions, I had already tried it, and as you say, it sure works. My real problem with this is that the limitation described above makes it awfully hard to solve some problems.
Here's an example of what I wanted to do: I wanted to filter a node set based on a value. For example I wanted to be able to do something like this on my XSLT:
Now, in FilterNodeSet(), I wanted to be able to take a node-set as the first argument (thus an instance of
XPathNodeIterator), and filter it based on the criteria specified on the second argument. Based on the code above, I would've wanted FilterNodeSet() to return a node-set containing /root/element instances, filtered by the @parent attribute (iow, select only one element for each possible value of @parent).
So, the idea I wanted to try was to have FilterNodeSet() build an instance of a custom
XPathNodeIterator-derived class that wrapped the original node-set and simply skipped over those nodes I wasn't interested on. Keep in mind this was mostly done as an exercise, to see what I could do with the .NET XSLT support, so it might not look like much ;)