I built my own keyboard firmware (https://gitlab.com/hakfoo1/ch32v-keyboard https://gitlab.com/hakfoo1/ch32v-keyboard) because I wanted to use a specific contro

I built my own keyboard firmware (https://gitlab.com/hakfoo1/ch32v-keyboard https://gitlab.com/hakfoo1/ch32v-keyboard) because I wanted to use a specific controller QMK didn't support, and the actual keyboard stuff isn't that complex (like 1k lines of C atop the vendor-supplied USB libraries). But it's not that configurable. It's got the usual assortment of custom keymap and macro support, but it's all stuff where you have to edit and recompile to change it. "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. When the entire controller has 128k of flash, and the actual firmware is using already burning through 60k of that, how much do you want to spend on that? I suspect that's why things like Soarer's Controller firmware (and perhaps VIA, I haven't studied it intensely) rely on the host doing the compilation. Also, in my mind, programmability is one of those things that is very fast diminishing returns until a project moves form "single developer passion project" to "widely used major project." Even though I can, I rarely do change the bindings and macros. From that perspective, the hassle of recompilation is far smaller than trying to invent a way to dynamically change the mapping. It might be much more important if my audience were bigger than one user-- new people will want an easy way to bootstrap from a default image to actually match their needs.