- if you double click the reset button, it waits a LOOONG time for a serial.
That's an interesting idea, how does it work? What survives a reset?
I think that it would be possible to write a sketch that updated the bootloader. I mean why not? Its just writing to flash. The problem with this idea is that if the sketch was interrupted mid-write your board would be bricked -- you'd have to buy a $20 ICSP to recover it. So maybe its not worth the support calls it would generate. What do you think?
A few things:
0. I think all techniques that reflash the bootloader brick the chip if the power fails at a bad point in time.
- Could you reduce the period of time when the system is vulnerable to power failure by downloading the bootloader (e.g. into RAM/EEPROM), and then blowing as quickly as practical from an on-chip copy?
A sketch to update the bootloader might be useful for leolfs use case (but I didn't understand it, so I may be wrong).
My favourite approach to flashing a chip is the FTDI bit-banging programmer "Burning the Bootloader without external AVR-Writer" which shows a technique for using the unused FTDI pins to program the ATmega.
If boards implemented that in an easy-to-connect way, and avrdude and the Arduino IDE supported it, then it would always be practical to recover a bricked-chip for minimal cost (a cable).
I assume we'll get Arduino/Freeduino boards like the Freeduino SB which implement an AVR programmer using only the FTDI chip. It makes perfect sense. Then reprogramming the bootloder may become a more natural activity.
A reflash-the-bootloader-sketch might be useful and good fun while we wait for everyone to make boards that way.
If your bootloader is very small, can you also include an ICSP programmer in the bootloader, so that one Arduino can program another? (like MegaISP and ArduinoISP but in the bootloader)
Then all anyone needs to bootstrap a new AVR-based board (including an Arduino) is an Arduino 
GB