I haven't assessed the patch, but wouldn't mind to see it applied to 
an alpha release or to 3.0; +0 from me.  Given that the next 2.6 release
is planned to be a beta, though, the release manager would have to rule.

Note that I don't think this change is actually backwards-incompatible
and is actually fairly low-risk.  It does change what re.escape will
return, but the common use-case is escaping some user- or data-supplied
string so that it can be passed to re.compile()without triggering a
syntax error or very long loop.  In that use-case, whether it returns _
or \_ is immaterial; the result is the same.  Doing a Google code search
for re.escape confirms that this is the general usage.

Interestingly, SCons defines its own re_escape, with a comment saying '#
re.escape escapes too much'.  But their function doesn't escape \ or $
at all, so I don't understand why they bothered.

On the other hand, if this patch doesn't affect the usage of the
function, why bother?  Matching Perl or other systems probably won't
improve interoperability very much, so the release manager might decide
to leave well enough alone.