I believe I found the bug.  For IDLE's original single process mode, still available with the -n startup option, debugger.py contains the entire debugger.  The values displayed for global and local names are obtained with reprlib.Repr.repr.  That in turn calls .repr1, and that calls .repr_xxx, where xxx is one of the 'common' builtin classes or 'instance'.

The latter is used for all user classes.  It calls __builtins__.repr, but guarded by 'try...except Exception' since user classes may cause exceptions.  The except clause returns an alternative type and id string, like object.__repr__.  (That alternative could also raise, but much less often.  Any of the examples above should run if IDLE were started from a command line with 'python -m idlelib -n'.

When user code is run in a separate process, the code that interacts with user object must also run in the separate process.  debugger.Idb is moved and the code in debugger_r is added, some in each process.  Of concern here is that the GUI code that displays global or local values is passed a dict proxy instead of an actual namespace dict.  The proxy __getitem__ for d[key] makes an rpc call to through the socket connection to code in the user process.  That returns not the object itself but a string representation.  It does so with an unguarded repr call.

IDLE intentionally removes traceback lines added by IDLE (and pdb, if used), so that tracebacks look mostly the same as in standard CPython.  But that is a handicap when there is a bug in IDLE.  A traceback ending with 
  File .../idlelib/debugger_r, line 173, in dict_item
    value = repr(value)
AttributeError: ...

would have been a big help here.  I am thinking about how to selectively disable traceback cleanup.

In any case, I believe the solution is to import reprlib in debugger_r also and add 'reprlib.Repr' before 'repr' in the line above.