Re: trimWhitespace vs keepWhitespace: it turns out the XmlSlurper's keepWhitespace and XmlParser's trimWhitespace are totally different beasts/concepts!
Firstly, XmlParser's trimWhitespace: it causes ".trim()" to be called on element text values (but not attributes!). It really does have the wrong default value but would break legacy code if we changed it. I would nearly support changing it anyway as a breaking change in 2.0. But given that we want to put a new api over the top (and potentially rework some of the internals) do we break user's code once or twice? It is well documented and easy to turn off - so the current thinking is to leave it until we make the api changes - but feel free to debate further - though it isn't really part of this issue per say.
Secondly, XmlSlurper's keepWhitespace: this is about preserving layout of XML documents. So if we have this XML fragment:
when the flag is off, parsing this will return two elements, "foo" and "bar". When the flag is on, this will return a "foo" element, then a "text node" containing a newline and 4 spaces, then the "bar" element. If you want to process the document content, the "whitespace text nodes" are just unwanted noise. But if you want to preserve the original layout of the document after making some changes to the content, then keeping the flag on can be useful. From memory, XmlSlurper may not allow full round-tripping anyway as it may not keep everything intact, e.g. processing instructions, XML comments etc. (but I haven't checked the code just now so don't quote me on this - we have made it cover more of these things over time)