Summary: With IDLE running normally, with 2 processes, "input('prompt')" in the main thread blocks execution of "print('whatever')" in a separate thread.  (Verified on Windows with 3.9 and macOS with 3.8.)  The user can respond to the prompt without being disrupted by continued output.

For standard single process python or IDLE (started with -n), the thread output continues and can be mixed in with both the input prompt and user response and in the example, scroll prompt and even initial response off the screen.

I presume the difference is related to IDLE routing user-code use of the std streams through a 3rd thread that manages the inter-process socket connection.  But I did not see why after more than an hour of looking.

Overall, I think the experience with input() in IDLE is more useful and less confusing, especially to beginners.  (I am having trouble imagining when the intermixing and interference would be useful.)

Guido, do you have any recollection of whether the IDLE difference, when using an execution process, is intended?  Do you regard intermixing input prompts and responses and thread output as a required feature of Python, or as an (unfortunate, IMHO) side-effect of using a dumb text interface?

Note: in IDLE, '>>>' come from IDLE, not the usercode execution process.  Hence a) asynchonous outputs from the execution process can appear on the screen, and b) IDLE, unlike the standard REPL, can and does prevents such text from mixing into and spoiling user code input.  (It may appear after '>>>' but is put before the input area.  This is an intentional interface difference.

My *immediate* inclination is to regard the IDLE difference as overall being a positive feature and leave it alone.  But it should be documented in "Running user code", which is already mostly about stdio differences.  

I don't deny that blocking output while a user responds is a negative.  I just see mixing streams as worse.  To work towards not blocking while not mixing, I replaced the thread loop with
    for i in range(10): sys.stdout.write(f'some text {i}\n')
and separated input(prompt) into sys.stdout.write(prompt) and sys.stdin.readline().

Observations:
1. .write is better as it is atomic, while print() prints '\n' separately, with sometimes undesirable results.
2. The block is from readline.
3. While output to Shell is blocked on readline, typing a continuation-invoking '.' or calltip-invoking '(' in either Shell or editor allows one line of output.  Both send a non-stdio message from Shell to the run process and back.  This might be a clue as to how read/readline blocks.

In the longer term, after some changes to Shell, I could imagine replacing __builtins__.input with a function that would check if sys.stdin/out were IDLE's replacements and if so, send the prompt to Shell tagged as 'prompt' rather than as 'stdout', so that Shell could keep prompt and user response  separate from regular output, similar to the way now done for code input.  If .readline cannot be made to not block output, it might work for Shell to send  the response back tagged as 'response' rather than as 'stdin' and not use readline.