gpsbabel remembers the xsi_schema_location from a read and uses it on a write, but does not remember the gpx version.   gpx.c has a comment:
        /*
         * Our handling of schemaLocation really is weird.
         * If we see we have a "normal" GPX 1.1 header, on read,
         * flip our default on write to use that and don't append
         * it to the rest...
         */

This can result in the xml element attributes version, xmlns and xsi:schemaLocation referencing different gpx versions.  This can be demonstrated by converting a version 1.1 gpx file to gpx:

gpsbabel -i gpx -f reference/expertgps.gpx -o gpx -F test.gpx

The xml element of then input file, expertgps.gpx is
<gpx
 version="1.1"
 creator="ExpertGPS 1.3.7 - http://www.topografix.com"
 xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
 xmlns="http://www.topografix.com/GPX/1/1"
 xsi:schemaLocation="http://www.topografix.com/GPX/1/1 http://www.topografix.com/GPX/1/1/gpx.xsd">

The xml element of the output file, test.gpx is
<gpx
  version="1.0"
  creator="GPSBabel - http://www.gpsbabel.org"
  xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
  xmlns="http://www.topografix.com/GPX/1/0"
  xsi:schemaLocation="http://www.topografix.com/GPX/1/1 http://www.topografix.com/GPX/1/1/gpx.xsd">

Also, it appears the static variable gpx_version is never used.  It is set in gpx.c and the related file garmin_device_xml.h.

I realize that I could have forced the output version by using the gpxver option, i.e.
gpsbabel -i gpx -f reference/expertgps.gpx -o gpx,gpxver="1.1" -F xx.gpx
However, this would the user to know the input file gpx version.

This test was run with code checked out today using Mac OS X 10.6.4.

Is any bug tracking system other than this mailing list in use for gpsbabel?

Best Regards,
Steve