Ok, let's get some things clear.
First, mindbender mentioned a file called uboot.buffalo being stored in /dev/sda1. Well, that is actually the u-boot binary itself. In the stock firmwares, /boot was used to store backups of the updated files, i.e. hddrootfs.tgz, image.zip, etc. The problem was, that it had problems when trying to update, because there would not be enough free space in /boot, hence why we now suggest people use the alternative initrd before updating any firmware (the initrd clears the backups in boot to make room for the update). That said, uboot.buffalo was on the lspro, too. It serves no purpose in /boot other than a backup.
Now, it was also mentioned that u-boot is being called TINY. That is not suspicious. TINY means that the binary is compiled with a config for a 256kb binary rather than the standard 512 binary. That's all.
The original u-boot on the lspro, was a "TINY" version as well. This information is actually noted in the source code documentation. I currently have the same version of u-boot for the "new" ls live, running on my lspro, and it is the TINY version.
Note though, there is an important issue with the different uboots (which is very stupid in my opinion). Each u-boot contains a function that holds the product id for the box. The product ids are obviously different for the LS Pro, Kuro Pro, and LS Live. In the original kernel, the microctrlv2 would check the product id reported by u-boot to verify the setup. This has been somewhat circumvented now in the custom kernels.
However, the schema for checking product ids seems to be enhanced with the stock 2.6.16 version of the firmware.
That said, here's my thought on what is happening"
1) For the old arm9 boxes, buffalo never released an updated u-boot publicly, therefore, u-boot never needed to be updated, thus we did not have any flashing problems. Nothing actually got "flashed" when the updates were performed ... flash meaning writing to the on board flash chip ... as u-boot is the only thing that resides in flash (kuropro ... different story).
2) The newer ls / lives actually contained a newer u-boot, and therefore, users trying to flash different firmware actually ran into problems, because the updater detected a different u-boot and attempted to update the u-boot, to which the on-board updater rejected, and thus borked the boxes.
What can be done about that:
Well, a standard u-boot would be nice. The codebase for each uboot for the TSPv2, LSPro, LSLive, Kuro Pro is the same, so we need to standardize u-boot, and make it truly generic.
Current situation: just remove the darn u-boots from the updater packages, and use the debug-method of updating, selecting that "boot" not be updated.
Hope this helps guys.