But I think it would be considered just a minor, and likely rarely occurring, annoyance. The same risk applies to the existing system EEPROM settings in the first 16 bytes. A garbage user name could start appearing at the end of the boot logo sequence or a legitimately set name could be corrupted. The sounds in all games could stop because the audio mute flag gets set. The boot logo or RGB LED could start appearing on power up after the user has set the flags to disable them. Etc., etc…
It would also be annoying for someone to see their high score or level achievement corrupted because you suddenly started using the last location, that a game (any game) was previously legally allowed to use. Like I said, you can’t police all the games that are already out there. You don’t even know about the existence of some of them. And, you can’t prevent EEPROM corruption due to errors made during program development.
Keep in mind too, that there are utilities written for the Arduboy for clearing out EEPROM. Unless you can find them all (which, of course, you can’t) and alter them, someone using one could cause your issue. Some of these utilities, such as the Arduboy2 library’s setSystemEEPROM, give the option of only clearing the user area and leaving the system area unchanged. Unless the utility is altered, doing this would wipe out the last byte of EEPROM, thus affecting your bootloader flag(s), but not the first byte, so you wouldn’t have this problem if you used it instead.
In one way, having these minor annoyances could be considered a somewhat good thing. It highlights when a sketch is using the reserved area, allowing the author to be made aware of it, and (or at least) get the problem corrected. At the same time, if the discussion is public, it educates other developers about the existence of system EEPROM and it being off limits.
Also you were concerned about wasting EEPROM space (like using a whole new byte when you only needed a one bit flag). By using the last byte of EEPROM you’re not only taking over a byte that a sketch could use, or is already using, you’re also leaving the first EEPROM address still unused and “wasted”.
And I have to ask, how do you plan to document the fact that the last byte is now off limits, in a way that a good majority of developers are made aware of it?
All this because using the last address may have less chance (but not no chance) of being corrupted than the first.