The FT232R bit-bang mode pins (CTS / DSR / DCD / RI) are brought to 4 pads named "X3" in all Arduinos, however, those pins are never located at the same place on the board depending on the version, and they are in the middle of the boards making their use impractical. I would suggest to give the X3 connector a well defined location at the edge of the board, lined up with the existing IO pins, where the "MADE IN ITALY" blank part is or on the lower part, to the left of the RESET pin. This second option would be a bit more tricky regarding PCB routing, but much better as it would allow a continuous connector (impossible on the upper side because of the mounting hole). If this is done, it would be wise to exchange pins 3 & 4 (DCD & RI) and add a second 3 pads row with +5V, the RI signal and GND. A 4th pad with +3.3V would be nice too (that would be a 4x2 header / pads) if placed on the upper left corner) else, FT232R pin 14 (CBUS3) would be more useful since a +3.3V pin is already located close. That way the 4 pins could be used by shields AND it would create a standard 6 pins AVR ICSP programmer that can be linked directly to the normal ICSP header with a flat cable to allow easy bootloader programing of bare chips with Avrdude (or directly from the IDE).
Here is my suggested pinout (if placed in the upper left corner) :
+5V DCD GND +3.3V ===> this row aligned with existing pins CTS DSR RI DCD ===> this row aligned with new "seeeduino" pins
or if placed on the lower left :
+5V DCD GND CBUS3 CTS DSR RI DCD ===> this row aligned with existing pins
ICSP bootloader programming connector is the 6 pins on the left.
Here is the currently required cable for ICSP programming that illustrate what I mean:
This could also be used among other things to directly read a logging data flash SPI chip shared between the bitbang pins and Arduino IO pins. The arduino would only do the logging (or use the data (programmed sequences, tables, sound, etc ...), depending on the application), data upload/download through USB being done directly by the host (faster, no need to waste code space to add a communication protocol on the Arduino itself, leaves the regular serial communication for other uses).
Another use would be to program an FPGA shield, opening a whole new world !
Creating a JTAG interface would be another use.
Yet another use would be to create a host controlled RX / TX multiplexer so that projects with multiple Arduinos can seamlessly share the same USB port (all other Arduinos would not need to have the USB interface, or could even be bare chips).
Giving a well defined location for this revised X3 interface (X4 ?) adds Zero manufacturing cost, does not interfere with existing shields, would be safe in case an "old" X3 cable is inserted (DCD and RI are both inputs by default) and I think it would really enhance the Arduino platform.
If this is done like the seeeduino (with 0.2 space between the 2 headers), it would be nice to fill that space with a V+ pin. the V+ pin would be defined as having the same voltage as the AVR chip supply (may that be 5V or 3.3V) to ease the transition toward 3.3V for shields that are compatible with both voltages. To the left, next to the AREF pin, a fixed +3.3V pin could be added. With those 2 pins, a single 18 pins header can be used instead of forcing the use of 2 separate connectors. The same V+ pin (or maybe an Analog6 pin for SMT AVRs ?) could be added on the other side of the board between Vin and Analog 0. To the left of the RESET pin, another pad could be added with the (currently unused) pin 12 of the FT232R (sleep) as it could be useful in applications that require power down and could be reprogrammed by the host (in the internal EEPROM) for other functions such as host controlled input or output, or even 6/12/24/48Mhz clock source (nice !). That way, another single 14 pins header can be used instead of forcing the use of 2 separate connectors. Finally, the X3 connector could be placed to the left of this additional pin, thus making the Arduino connector a simple 2x 18 pins device aligned on a 0.1 grid ... all without breaking compatibility.