Can you elaborate a little bit more? this sounds interesting!
[Note: very long and technical reply for Lanx or others interested. If you're not into long technical replies, please skip.]
Sure, I'd be glad to. The majority of firmware engineers (I'd say about 95% based on my own experience) do not know or care how to properly design firmware for working on flash memory. Even though they might be an experienced firmware engineer, and write very good code, they just somehow do not give proper thought to all that's involved in making the system work to it's full potential on flash memory.
Whether the code is running off of flash, EEPROM, EPROM, hard drive, or whatever, the basic code is the same. However, each storage technology has it's quirks which need to be addressed if writing to the storage medium, or updating firmware. A hard disc with a proper driver and OS is pretty easy. You just read/write/erase and don't need to do much else. Updating involves perhaps making a backup of the existing files and copying new files. Flash memory, in it's basic form, without an OS or driver (which would typically be the case for small embedded microcontrollers such as a keyboard), cannot simply use the read/write/erase that you would on a typical system with a hard disc.
First of all, flash memory size is probably very limited. So you might not be able to make a backup of the existing firmware before overwriting it with the new firmware. With ever declining prices of flash memory though, this is becoming more and more possible. So if possible, you need to have an algorithm which downloads the new firmware into a separate portion of flash memory, then verify it is correct, then finally write a code into flash memory to tell the bootloader to use the new verified firmware rather than the old firmware. If you don't have enough flash memory for two versions of the firmware, then you need to have a bootloader which is standalone (and typically which never gets updated), which can download new firmware in case the system gets reset or has some sort of a problem while downloading. This is pretty basic, but still some firmware engineers mess up here and design a system which isn't foolproof and allows the user to end up bricking their device by messing up during downloading new firmware. Basically, if you're going to design on flash, you must at a minimum make the system totally idiot proof. Under no circumstances should the firmware ever allow a user to be able to brick their device while upgrading, with the exception of someone who tries to circumvent the normal download process.
Beyond the firmware and updating it, you also have to consider data storage, and design an algorithm that takes into consideration the nature of flash. Flash memory has a limited number of times it can be erased and rewritten. Almost all firmware engineers I've come across totally fail to design the system with this in mind. Perhaps not so applicable to a keyboard controller, but very applicable in many other systems, is using the flash memory as a "last memory" storage device. For example, if you were designing a TV set where a microcontroller kept track of the last channel being watched, and power was cut to the microcontroller each time the TV was powered off, you'd want to save the currently viewed channel to flash memory whenever it was changed. So the typical firmware engineer that I've run across would code it to simply use a given block of flash memory to save the last channel number (and any other last memory or other settings), and if the user changes the channel, the system would erase that block and the write over the erased block with new information. This is a completely wrong approach. First, if the user is rapidly changing channels, you don't need to be saving to flash memory on each and every channel change. You set the last memory update routine up on a timer and if no changes have been made for some period of time (maybe a few seconds), then you write the changes. But you can't erase the existing block, because that would mean you'd lose all your settings if power was cut before you could save the new block. So most firmware engineers, if realizing this pitfall and attempting to overcome it, would simply write to a new block, then after successful completion would erase the old block and have the system be able to determine which of the two blocks contains information. That's fine, but if someone is just changing the channel, you're erasing and writing a new block each time the channel is changed (with respect to the timer function already mentioned). So back to the nature of flash memory with a limited number of times it can be erased and rewritten. This sort of an algorithm will greatly reduce the life of the device if it's frequently erasing and writing new blocks. If the flash device is rated at a million erases, it might be fine for just channel changes. If it's rated at 100,000 erases and the system updates flash for many reasons beyond just channel changes, and does so very frequently, the system will eventually fail simply because the flash memory was overused. So the best solution is to design an algorithm whereby records are stored inside a block of flash memory, and when the system is reset, it searches the block to find the last valid record and uses that. In addition, a minimum of two blocks are needed, for the case when one block is full but the new information must first be written before the old block is erased. Using this technique, a block of flash memory is never erased until after it is full, which could mean in some cases the amount of flash memory erasing required for a small amount of data stored inside a much larger flash memory block can be reduced to a small fraction of what it would without using this technique. Whatever technique is decided on, one must crunch the numbers and figure out what is the maximum number of erases that will happen over the product's expected lifetime when used in a normal manner, and to verify that this number is well within the flash memory device spec.
When writing all data, the firmware engineer must consider that the device might be powered off at any point, and partial saves might happen. Thus whenever saving data, the data itself must first be saved and confirmed, and finally a checksum of that must be written. Then when the data is read, it must verify the checksum. If the checksum is invalid, the data must be considered invalid. Of course this is all done automatically on a hard disc. In firmware though, you either need to find a well-tested library compatible with your device, or do it yourself.
Typical errors (bugs) in firmware are to be expected. It's the nature of the beast. All but the simplest of software will have some bugs. Thorough testing should be done before release so that the product is able to operate error free by the vast majority of users. But general bugs are easy to correct via downloading new firmware, so there's a limit economically in testing, beyond which it'll cost increasing larger amounts of money to find and fix a diminishing number of bugs. Flash bugs though can easily brick the device. Thus top priority must be given to careful coding and completely thorough testing/debugging of the flash functions.
I could go on, but I think it's probably over the heads of most here already. Nothing I've said is particularly difficult, but it is tedious and very time consuming and a lot of software engineers seem to want to just gloss over these issues and write their code quick and dirty, which will mean a certain percent of the devices will fail in the field. A well-run development team will see to it that proper flash memory algorithms are utilized, either designing their own code library in-house, or buying a well respected third-party library. Electronics firms which are not well-run and who concentrate on getting products to market without spending the necessary time and money to design them right will typically ignore points such as this. That's why when I seriously look into some product, one priority is to examine as best possible their firmware upgrade facilities. It tells me a lot about how well the product was designed. If the upgrade is poorly designed or non-existent, I'll likely consider other alternatives.
Professionally speaking, poorly designed flash algorithms is probably my biggest pet-peeve, which is why I'm so opinionated about this issue. Second biggest pet-peeve is poorly designed communications protocols with non-failsafe error detecting.
BTW, I don't mean any of these comments to be directed at the team who developed the OTD keyboard. They're also not directed at a hobbyist who just wants to make something for his own use, or for fellow hobbyists capable of downloading directly to a microcontroller. The comments are directed towards companies manufacturing flash-based electronics for mass consumption.