More than you want to know:
The details of the 28k problem are here:
http://code.google.com/p/arduino/issues/detail?id=380 and
http://code.google.com/p/optiboot/issues/detail?id=23fusebytes will only report the version for optiboot itself (there's no universally-agreed way to store "bootloader version" across all versions).
In order for "Fusebytes" to report the optiboot version number, you need to have both a version of optiboot that CONTAINS a version number, AND a slightly changed fuse configuration that allows the sketch to read that version. This change (
https://github.com/WestfW/Arduino/commit/39a496616f241a3908d7821dcb15520f16ecd871 ) to the fuses was rejected by the Arduino team (nervous about changing the fuse bytes!), and was made somewhat unnecessary by
https://github.com/WestfW/Arduino/commit/7b1ee0f1b0192143fffbbed66dc046b6568f4386 , which lets AVRDUDE see the correct version number.
If you run your sketch upload in verbose mode, somewhere within the output (use a short sketch) should be a report of the Firmware Version:
avrdude: Recv: . [03]
avrdude: Recv: . [10]
Hardware Version: 3
Firmware Version: 4.4
avrdude: Send: A [41] . [84] [20] This will show "3.3" for the old production version of optiboot (with the 28k bug), and "4.4" for the new production version of optiboot (with "most" bugs fixed.) It's slightly possible for an Arduino to be running a bootloader with the 28k fix and still be telling avrdude that it's running 3.3, if someone installed optiboot from the optiboot project source code, or from my Arduino fork, before that second commit was added (the 28k bug was actually fixed by the original optiboot author, JUST after the arduino team pulled the version they ended up using...)