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:
as a reminder, here's a page about this way to burn a bootloader :
the bitbang mode also opens new applications, such as direct access from the host to any SPI peripheral. Here are a few examples :
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.