It is unsafe to use a mod-rewrite rule that transfers a portion of the path into the query string.  This is 
because it is not possible to encode the matching portion of the path to be a safe query value.  For 
example, if I wanted to rewrite:
  /foo/bar+baz
into:
  proxy:http://www.domain.com/blah?arg=bar%2Bbaz [last]
I'm out of luck because it is impossible to translate the '+' in the path into it's query-string-safe 
equivalent, '%2B'.  As a result, the destination server will decode the query arg into "bar baz", removing 
the '+'.

According to the documentation, I can escape URLs using the RewriteMap directive:

  RewriteMap escape int:escape
  RewriteRule /foo/(.*) proxy:http://www.domain.com/blah?arg=${escape:$1} [last]

However, this doesn't work because the escape method doesn't do what one would expect based on 
casual reading of the docs.  The escape method is a pass-through to ap_escape_uri, which in turn is a 
macro for ap_os_escape_path.  The docs could reasonably lead one to believe that the escape method 
makes a string safe for use in a query string (i.e. url-encodes the string).  Instead, it makes the string 
safe for use as part of a file name.  (I think.)  Several query-string-unsafe characters are not encoded by 
this method, and the set of encoded characters varies from platform to platform.

I would recommend a fix that augments mod_rewrite's list of internal map functions.  First, deprecate 
int:escape.  Next, create int:escape_path which does the same thing that the deprecated int:escape 
does.  Last, create int:escape_query which url-encodes the value for safe use as a query-string value.

If there is general agreement that this is the correct fix but developer resources are lacking, let me 
know (or re-assign to me) and I can take a stab at creating a patch.  (Although it may be a long while in 
coming.)