both problems; messages can be wrapped for readability and you can still include arbitrary stretches of whitespace in the expression.
Hmm... and what about multi-line messages?
That's why I'm suggesting this as an optional behavior -- that way (a) it doesn't affect existing configurations, and (b) you can actually put multi-line patterns in place if you need them. If you know you need to match multi-line patterns, don't enable whitespace collapsing. Another idea would be to adopt the syntax used by Perl and Python's "extended" regular expressions -- this requires that any whitespace be specified explicitly. So this: this \s is \s a \s test Is the same as: this \s is \s a \s test And of course you can make newlines explicit via \n and so forth. Actually, the more we wander down this path the more I wish I could just use PCRE-style regular expressions as long as I was willing to put up with the performance impact.