Researching 'nested mainloop': the one we are concerned with is in pyshell.PyShell.readline, currently line 1078.

            self.top.mainloop()  # nested mainloop()

This was in David Scherer's 'Initial Revision' of 2000 Aug 14 without the comment.  It has since been touched once to add the comment.

2004 Dec 22, KBK, 5c3df35b6b1f48cb48c91b0c7a8754590a694171.
The GUI was hanging if the shell window was closed while a raw_input() was pending.  Restored the quit() of the readline() mainloop().
http://mail.python.org/pipermail/idle-dev/2004-December/002307.html

So no hint of reason.
---

https://stackoverflow.com/questions/17252056/tkinter-nested-mainloop
OP asked about using a nested mainloop for a video player.  There is discussion (dispute) of whether or not this blocked the mainloop.  Tkinter expert Bryan Oakley opined "While it's possible, there is very rarely ever a need to call it. reason to do it, and what you are trying to do probably won't work the way you think it will. –" 

OP Raoul quoted FL "Event loops can be nested; it's ok to call mainloop from within an event handler." (dead link to draft version). It is now in mainloop entry of https://effbot.org/tkinterbook/widget.htm.  There is no explanation of why or what effect.
---

Mark Lutz, Programming Python, discusses recursive mainloop calls as an alternative way to make modal dialogs, without 'wait' and other setup calls.  In the 3rd edition, displayed by Google Books, the half page is expanded to a full page (442-443, Example 9-14, PP3E/Gui/Tour/dlg-recursive.py) and he adds that calling quit() is mandatory (see KBK patch above) and that using 'wait', etc, is 'probably better'.  The latter is what IDLE does.  Since 'modal' means 'disable event handling outside the dialog', the intent must be to suspend the outer event loop, as we see for this issue.
---

While I still think that IDLE should protect user code input in response to *IDLE's* '>>>' prompt, even more than it does now, I now agree that IDLE should not do the same with try user *input()* calls.  The usability of the latter is the responsibility of users who write them.

Not blocking thread prints may just be a matter of removing mainloop() and all corresponding quit() calls.  Proper sequencing may be trickier.  Tem4.py calls input() and print() from both main and thread.  Run directly with 3.9.0b1, it results in

thread start
main input: m  # wait before entering 'm\n'.
main got:  m
thread input: t
thread got:  t

What surprised me is 'thread input:' being held up until 'main got' was printed.  Run from IDLE, the result is

thread startmain input: 
m
thread input: main got: t
 thread got: m 
t

This is more jumbled, not less.  'main input:' is printed before the '\n' after 'thread start'.  etc.  Separating print(...input()) into two statements had no effect.  Neither did removing sleep(.1).  We will have to retest after blocking is removed.