I don't believe that the LocationMatch/DirectoryMatch/FilesMatch sections
allow negatives.  The "!" syntax is certainly not documented anywhere.

I guess we could consider this bug report a request for such ability.  I have
seen it requested elsewhere, and it shouldn't be that difficult to provide.

As far as your particular problem, it should be easy to get around using something
like
RewriteEngine On
RewriteCond %{REQUEST_URI} !^/bar
RewriteRule / http://somehost/ [P]

It's possible support for such does not exist,
I found examples of it out there on the web
though. However "regexp" is a nebulous term,
and I was unable to find anything specific in
the documentation concerning exactly what
regexp syntax was supported... (although
from looking at the source tree it seems pcre
is used, in which case it seems negation would
be extraordinarily easy)

The rewriterule while one means of a workaround,
does not emulate the desired behavior. I am
trying to proxypass from somehost such that
the content appears to come from this host.
(I'm actually proxying an apache 1.3 server
bound to 127.0.0.1).

I did think of workaround, which I have not
tests, that is more of a hack and hideous.

"/[^b][^a][^r]"

The RewriteRule does work.  Please look at the docs for RewriteRule with 
specific reference to the "P" option which stands for Proxy.

Heh, so does it. Sorry about that.
(Though it appears the last line needs to be
    RewriteRule /(.*) http://localhost/$1 [P]
)

Just for the records:

<LocationMatch "^/(?!bar)">

works, too (since httpd-2), because of the advantages of pcre. The syntax is
described and explained in perldoc perlre. (which is online at perldoc.com).
No need to duplicate that manual stuff within the apache docs.

Thanks for using Apache!

I'm surprised this isn't considered a useful enhancement. Negative matching is an integral part of 
regular expressions, and the fact that it's missing from the *Match directives is, to me, a serious 
oversight. It seems very backwards to me to suggest that, since it can be worked around using other 
features (without having identical functionality), this is not a useful feature to include.

I would like to petition the devs to reconsider adding this functionality. If there is some reason I have 
overlooked that it would be dangerous or impractical for this to be added, I am very open to feedback.

For reference, here are a few threads I found on Google, some of which express the same incredulity 
that this feature is not present, some of which are simply pleas for help on how to accomplish the same 
functionality. Note that in most, the negative assertion workaround is the recommended solution.

http://mathforum.org/epigone/modperl/lulsmoxkhi
http://www.mail-archive.com/tomcat-user@jakarta.apache.org/msg145973.html
http://www.apache-httpd.com/msg/5514.html
http://www.issociate.de/board/post/167026/Exclude_images_from_match.html

I found another resource containing a quote which sums up the lack of negative matching pretty well:

"This option was added for two reasons - firstly that the <LocationMatch> directive is not allowed in a 
.htaccess file, and secondly that the built in Apache regular expressions are not terribly powerful (for 
example they cannot do negative matches)."

Source: http://www.axkit.org/docs/guide.dkb?section=7

It would be spectacular to see a simple, no-nonsense negation.  From
what I understand after skimming the PCRE man page, this has to be
external to the regexp because of the nature of regexp matching.
Probably why it was never implemented, because it's extra work.  Maybe
other things needed more attention so this was put aside, then
forgotten about.

FYI for those searching for answers, the "^/(?!bar)" syntax is referred
to as a negative assertion.  It has some subtle syntax and can be a bit
confusing for the novice PCRE user even in a simple case, which may be
many of the admin running Apache.  I'm not too familiar with how nice it
plays with more complex regular expressions.

In the config file, it's difficult if not impossible to specify each
negative Match rule for every possible negative Match condition when the
negative results may change frequently and at random, yet the positive
Match are few and static.  These cases seem to be very common.  If a
regexp does not match the right answer, tell me it's the wrong answer.
I won't sit and try to pre-define every conceivable wrong answer in the
universe, when there are maybe 3-4 right answers that I care about.
That is computationally wasteful and redundant.

LocationMatch is part of the core.  What if I don't want to use
mod_rewrite for every tiny thing that isn't properly implemented in the
core?  I want to keep the server lean.  It's a shame to have to include
another module to do something that LocationMatch (from the view of a
sysadmin) should be able to handle within it's own syntax.  It's 95%
there already when the PCRE returns and finds that there was no match.
The PCRE function returns -1?  So if there's a "!" negation character,
check for "-1" return, and if so valued, perform the action specified.

I'd have to look into the code and research more to see if there were
any patches or to generate one.  I'm surprised that in all this time
there have been no patches.  Maybe it's uglier than I think in there.

Closing bug report due to inactivity and the issue is rather cosmetic.
If more information appears later, please re-open the bug.