I have some different ideas for this issue that would not necessarily involve removing -n.  While -n is can be an inferior experience for users (user code blocks the GUI, other interference, especially tkinter), the reason given for deprecation is to simplify IDLE maintenance by eliminating alternate code paths.

Summary: a new rpc_local module might allow us to simplify code now, without removing -n, and provide a path to switching subprocess communication from sockets to pipes.

1. Simplify maintenance by instead isolating -n code in a new 'rpc_local' module that is imported 'as rpc' when -n is given.  (A 'run_local' module might also be needed.)  The goal would be to have the rest of IDLE as oblivious as possible as to where user code is executed.  Other modules would send messages via rpc and not know whether they go to another process (currently via a socket) or or back to the main thread in the same process.  I don't know how far this is possible.  It would certainly involve some refactoring.

2. Make rpc_local less of a dummy by executing user code in a separate thread connected by a pair of Queues (and call it rpc_thread).  I believe this would solve the problem of user code freezing IDLE.  On the other hand, it might make user code importing tkinter worse.  If so, I would consider declaring that unsupported and not run code containing 'tkinter'.  Perhaps I am overlooking some important reason a thread is not already used.

3. If rpc_thread worked, multiprocessing could be used to turn it into a new rpc remote process module that communicated with pipes instead of socket ports.