The main thing the patch does is:
modify the subprocess restart procedure so that it reloads
whatever file, if any, was loaded when IDLE first started and looked for
IDLESTARTUP then PYTHONSTARTUP environment variables.

In addition:
a -q option is added for starting IDLE on the command line to
mean "quiet", as with Emacs, e.g., to suppress loading of IDLESTARTUP or
PYTHONSTARTUP
The former effect of -s would now be the default, which is
desirable so double-clicking an IDLE icon to start it will cause the
startup file to run.
-s is changed to take an argument that is an alternate startup
file to use

I am a bit concerned about changing -s to have a different meaning.
Perhaps it's better to leave -s as an option that is simplhy superfluous
and use a different letter for the alternate startup.

Adding patch for 3.1 from bpo-5234 to this as per Martin's request.

Assigning to kbk since 5234 was assigned to him.

Oops! Mitchell's patch didn't actually run the startup code after restart. Fixed patch attached (updated against 2.7 trunk). Also added some doc updates. Too lazy to produce a 3.2 version now.

[Apology to Mitchell: I removed most of your comments explaining the change and attributing it to you. Nothing personal, just that's we have version control to store that info.]

Open questions / doubts:

• I described it in Lib/idlelib/NEWS.txt - correct?

• There is much duplication between the Doc/library/idle.rst, the command-line help string in PyShell.py and the option parsing code. Maybe it should be rewritten with optparse? [Doesn't block this patch.]

• There is much duplication between begin()/start_subprocess() and restart_subprocess(). These pieces of the code have a history of being fragile, and having subtle differences between them is a bad idea :-( I didn't dare refactor them as I can't test such changes widely enough, so the startup call is duplicated.

• When a script is being run, should the startup file run before or after it (or at all)? Currently it runs before the script, which is good because it can e.g. set the excepthook, and bad because it's different from running in a clean Python. (Python doesn't run PYTHONSTARTUP at all when running a script, even in -i mode.)
  Opinions? Anyway, it's hard to implement otherwise with currect runcode().

[Unrelated to the patch but bothering me: it seems that runcode() sometimes restart the shell and sometimes not, and is used in both capacities?! This is very confusing. Or am I just reading it wrong?]

This is at least 2 issues: startup and restart. I closed bpo-8378 as a partial duplicate of the startup issue.

For startup, I reject the idea of changing the default and the meaning of -s. First, it would break the general back-compatibility policy and possibly break scripts of people who read the doc and proceeded accordingly. Second, while I generally prefer Idle to match the console interpreter, there is an important difference in having tkinter and idlelib modules involved. A startup script that works fine for the console could create subtle bugs in Idle. I suspect that whoever chose the current default had some thought like this. To put this a different way, running idle is similar to running 'python -i idle' and python does not run startup files with -i. Third, this change shuffles responsibilities around without any net gain that I see.

bpo-5594 suggests adding startup options to the configuration file and dialog. I like this better and consider it possible.

For restart, the result of Restart Shell Cntl-F6 should be the same as an initial start (without running a file from the editor). On the other hand, I agree with Beni's concern about matching python -i when running editor files.

I also agree with Beni that the run... functions should be reviewed for possible refactoring, and, sadly, that testing is difficult. We would need a test script that documents both current and desired behavior and people to run it (by hand and eye) on Windows, Linux, and Mac.

Related issue bpo-22893 is about __future__ statements in startup code having effect on future interactive input in the same way as it does with Python itself. I think a pure Shell start/restart (cntl-F6) should be handled separately from a restart that is a side-effect of running an editor file. There is a separate proposal to specify an individual file's startup condition (sys.args + STARTUP file). For Shell restart, a possible reason might be to get rid of the effect of a STARTUP file. Since ^F6 is rarely used (I think), asking whether to include the STARTUP might not be too intrusive.

I think default behaviors should follow Python, though we can add more. On the other hand, Python has startup options not currently available with Idle.

Re my comment about handling Shell restarts differently for Shell restart cntlF6 and Run module F5: Python only runs "PYTHONSTARTUP" for interactive move. From the manual: "If this is the name of a readable file, the Python commands in that file are executed before the first prompt is displayed in interactive mode." When -s is passed, Idle opens Shell for sure and executes the file there.

A new patch is needed to optionally rerun startup stuff (including future imports, see bpo-22893) with ^F6 restarts. I think a combined patch might better be attached to the other issue, where I did some analysis on the changes needed.

I guess the point of automatically reading is that python does also, at least for PYTHONSTARTUP. I don't know Idle is different. However, the main point of this issue is about restarts.