IDLE is sufficiently undocumented that I think we may, *if necessary*, treat the details of 'expected behavior' as undefined, or look to other programs for guidance. Certainly, 'crash' is unexpected and undesired ;-).

Without "[] Regular expression" checked, I expect a simple 'normal mode' "find the literal string and replace with literal string" behavior. This is how Notepad and Notepad++ work. Neither has any problem with trailing '\'. The main 'special chars' I noticed are those normally significant to dialogs: the [Tab] key advances focus, [Enter] key executes the currently highlighted command. (The other two programs start with [Find] rather than [Replace] selected, but that is a minor and visually noticeable detail.) ^C and ^V work as expected in the entry boxes, other control chars beep.

In this mode, it is an implementation detail that the re module is used, and it should be transparent that it is. So 'backreferences' are meaningless. But in regular expression mode, they should act as an experienced re user would expect. (What that is, I an not sure, as I am not such ;-).

Notepad++ separates 'Regular expression' from the other options and has a boxed three-button radio group

|-Search mode-------------------------| 
| () Normal                           |
| () Extended (\n, \r, \t, \0, \x...) |
| () Regular expression               |
|-------------------------------------|

These amount to treating the find/replace entries as uninterpreted string literals (as with input()*), cooked \-interpreted string literals, and as (raw literal) relational expressions. We could consider Extended mode as a new feature.

* While raw string literals do not allow training '\', the input function does (in the standard interpreter window)

>>> print(input())
abc\
abc\

However, this does *not* work in IDLE 3.2.2, Win 7:

>>> print(input())
abd\  [hit Enter here]
      [which IDLE echoes here]
      [must Enter again]
      [which IDLE echoes again]
>>>   [to get new prompt]
>>> x=input()
abc\
     

>>> x
''

Entering "a\bc" is also messed up:

>>> x=input()
a\bc

>>> x
''
>>> x=input()
a\bc
>>> x
'a\\bc'

The difference between the two above involves the IDLE history mechanism, which (wrongly, in my view) treats response to input() as part of the statement.

I wonder if this is related to the current bug. Does the replace dialog use input()? Or is input entirely handled by tk, and should I open another report?

Ezio's other point:
'''
m = prog.match(chars, col)
if not prog:
    return False
...
I think that "if not prog" in the snippet I pasted should be "if not m".  Pattern objects are always True (I assume prog is always a pattern object).'''

I would guess that you are correct and this should be fixed also.