The re module seems to treat the raw strings as normal strings:
>>> 'a1a1a'.replace('1', r'\n') == re.sub('1', r'\n', 'a1a1a')
False
>>> 'a1a1a'.replace('1', '\n') == re.sub('1', r'\n', 'a1a1a')
True
In the first line str.replace and re.sub should perform exactly the same
operation and return the same result but re.sub replaces the 1s with
newlines, instead of a literal '\' and 'n'.
The second line should evaluate to False but re.sub replaces again the
1s with newlines so the result is equal to the LHS.

>>> re.search(r'\n', 'a\na')
<_sre.SRE_Match object at 0x00A81BF0>
>>> r'\n' in 'a\na'
False
Searching a r'\n' in a string that contains a newline also return a
result even if r'\n' is not in 'a\na'.

Tested with Py2.5 on Linux and Py2.4/2.6 on win.
The problem could be related to http://bugs.python.org/msg71861 
Attached there is a txt file with more examples.

No, re.sub()'s documentation
(http://docs.python.org/library/re.html#re.sub)
makes it clear that \ followed by n in the replacement string is
interpreted.

To insert \ followed by n you have to double the \ inside the raw string
like this:

>>> re.sub('a', r'\\n', 'abba')
'\\nbb\\n'
>>>

My bad, I only checked with help(re.sub).
In the examples with re.search I was indeed wrong because I forgot to
escape the \ and for the regex engine \n is the same of n (whereas \\n
is a literal \ followed by n), but I expected 'a1a1a'.replace('1',
r'\n') to return the same of re.sub('1', r'\n', 'a1a1a') because the
r'\n' is not a regex but a simple replacement string.
Also, the doc says "repl can be a string or a function; if it is a
string, any backslash escapes in it are processed. That is, \n is
converted to a single newline character, \r is converted to a linefeed,
and so forth.", this is the standard behavior of normal string, it
should be mentioned that the backslashes are processed even if with raw
strings and they need to be escaped with two \.
I think that changing the behavior of what is supposed to be a "normal
string" (the repl string) is not really a good idea (even if it's useful
when you have things like '\1\n' and assuming that this is why it has
different behavior), I'd rather prefer to use $1 instead of \1. Unlike
'\1', (as far as I know) $1 has no special meaning in Python so there
won't be any problem with raw strings.

Re-opening as a documentation bug; we should at least make the re.sub
docstring match the text documentation.

IIUC, there is no proposed patch yet, so this is out of scope for 2.5.3.

Eh? It's just a doc bug now.

> Eh? It's just a doc bug now.

[assuming you are wondering why it is out of scope for 2.5.3]
I don't understand the actual issue (and don't have time to find out
what it is), so somebody else would have to provide a patch. Since there
is no patch, this issue likely misses 2.5.3 (if it is just an error
in a doc string, I don't find it particularly necessary to fix it
in the bug fix release, either).

Added a bit to the re.sub(n) docstrings in r68118.