There's another problem with this LUFA-based bootloader -- it is executing SPM instruction sequences with interrupts enabled. The chance of this causing a failure is pretty small because the timing requirements would be very tight -- but it will happen. I've submitted this as an issue on GitHub.
If anyone is interested, I've managed to get a bootloader running with the latest LUFA version (170418) and it is using the boot key value located at (RAMEND-1) where it won't trash any user data. While this is tweaked for the processor (ATmega32U4) and board I'm using, others may find it of some use. I'll be glad to share if anyone is interested.
One other point too. The bootloader can pass the initial value of MCUSR (i.e. cause of the reset) to the sketch in a MCU register, but there's still an ambiguity in the case of a WDT reset. This is because the Arduino core (CDC.spp) uses a WDT reset to start the bootloader when the COM port is touched at 1200 baud. If a sketch is also using the WDT to reset the MCU, this creates ambiguity. Who caused the WDT reset -- the core or the sketch? There's an easy solution to this: the bootloader can use one of the unused bits the copy of MCUSR passed to the sketch to resolve the ambiguity.