IMHO A solder jumper is no good.
Because sometimes you want auto reset and sometimes you don't.
For example, you want auto reset for downloading because avrdude was not modified to create an arduino device that handled reseting the MCU specially so reseting the MCU to the bootloader depends on a hardware kludge to get the MCU reset pin automatically momentarily driven when the port is opened.
However, after burning the code and using the code in "normal operation" , you then may want to bring up an application to connect to the serial port to get status information from the Arduino board or send commands to the running board *without* resetting it.
So for this real-world use case, a solder jump is not good enough.
A switch works great. It is is very simple, and users can't really mess things up. There are only two options for a switch and users should be able to figure it out especially if the board is labeled. At a minimum they will be able to tell which switch controls reset operation and flip it both ways until it works the way they want it to.
Some of the "arduino" board makers have already seen the need for this capability and have incorporated it into their "arduino" boards:http://www.seeedstudio.com/blog/seeeduino-and-its-pals/http://www.nkcelectronics.com/seeeduino-fully-assembled--arduino-compatible.html
It is also possible to disable the arduino auto reset hardware kludge in s/w on many operating systems.
Part of the problem with this is that some OSes screw up their implementation of DTR and RTS so there can be issues.
On Ubuntu linux you can use the stty command with the hup/-hup options to control whether DTR is driven or not, which is what affects the RESET signal to the MCU when the port is opened/closed.
On windows, (at least some versions) you can set the advanced property setting for the com port "Set RTS on close"
which affects the DTR line (go figure).
While these OS settings can work for certain OSes,
there is nothing as simple and as reliable as a switch; especially
since it is not always possible to ensure that the OS has
the needed functionality or has been properly configured to not play with the DTR line when the port is opened/closed.