> "Flexible" programming, like "mount the keyboard as a psuedo-flash-drive and edit the config file on it", means sacrificing a lot of resources for the config

> "Flexible" programming, like "mount the keyboard as a psuedo-flash-drive and edit the config file on it", means sacrificing a lot of resources for the config file and parser, relative to a few pre-compiled data structures. Absolutely. But the bottom line for me is that it was trivial to tweak the Micropython keyboard to do what I wanted, and it's at least 10x more difficult to make the same change to a QMK board. Otherwise both keyboards work fine, so I don't really care about how many resources the programs are using on the boards. I also don't really want to go track down the source to recompile (if it's available) or figure out how to start from a generic QMK build and make it work. And I don't want to deal with the hassle of re-flashing it and testing to see whether it worked, troubleshooting bugs, etc. I agree with you that it's best to set up your keyboard however you want it, and leave it be. I haven't made any changes to mine since I tweaked it just after I bought it. But the ability to do those initial tweaks is pretty important IMO.