These are all based on real needs. It appears to me that none of these is implemented in 1.0 beta.
1. Additional member functions print_P and println_P in the Print class, for printing PROGMEM strings
I often see posts on the forum where users report that their sketches don't work since they added a small piece of apparently benign code. The usual reason is running out of RAM, and the most common reason for running out of RAM is use of a large number of string literals. The fix is to move the strings into PROGMEM, however they can't then be printed directly using e.g. Serial.print(). I suggest new member functions print_p(const PROGMEM char*) and println_p(const PROGMEM char*) in the Print class, similar to the corresponding print and println members but taking PROGMEM strings. This would allow for example:
Serial.println_p(PSTR("Hello world!"));
The _p suffix is in line with other functions that take PROGMEM strings. I have code available for these functions.
[EDIT: in fact the 1.0 release includes a new F() macro for creating strings in PROGMEM, and print/println are overloaded to support it - so print_p and println_p are not required. Thanks to CodingBadly for poinitng this out.]
2. Facility for hooking the tick interrupt
Many sketches need a regular tick interrupt, for example for polling buttons and rotary encoders. I usually use the MsTimer2 library to set up a tick interrupt. However, there is already a regular interrupt used to count millseconds, and it would make sense to hook into this instead, keeping timer 2 free for other uses. See http://www.arduino.cc/cgi-bin/yabb2/YaBB.pl?num=1293546475 for a possible implementation.
3. When compiling a sketch, as well as displaying the amount of Flash used, display the amount of RAM used by static data and string literals.
The IDE currently provides no clues to the user that lack of RAM may be an issue. In fact, lack of RAM is much more likely to be a problem than lack of Flash. See http://www.arduino.cc/cgi-bin/yabb2/YaBB.pl?num=1224729260/all for a possible implementation.
4. Configurable delay in analogRead() after switching the multiplexer
Another problem that I often see on the forums is users finding that analog pins 'interfere' with each other. The usual suggestion is to read from the pin twice, possibly with a delay between the two reads. However, it would be better to include a configurable delay in analogRead() itself, for two reasons:
(a) including a small amount of delay by default would avoid many users experiencing the problem in the first place;
(b) a delay is more effective than doing multiple analogRead() calls, i.e. a stable reading is achieved in a shorter time.
See Delay in analogRead after switching pin - #13 by dc42 - Libraries - Arduino Forum for more details and some measurements I took. The default delay of 10uS that I suggest adds less than 10% to the time taken by an analogRead() call. As an alternative to the suggestion I made in that post, the delay could be passed as an optional second parameter to analogRead().
5. Fix the bug that causes delayMicros(0) to delay for a very long time
This is the sort of bug that may go unnoticed, until an unsuspecting user calls delayMicros with a calculated delay time and the calculation just happens to return zero on rare occasions. See BUG: delayMicroseconds(0) leads to a huge delay - #8 by robtillaart - Libraries - Arduino Forum.