So nothing one might compare to actual support from a manufacturer, but in my opinion, enough to do something like this. Do you disagree?
Out of the three repos, two are native Chinese speakers, and I know one of them.
I guessed something along those lines

– any chance you might someday help with the datasheet translation? Say, if one prepares you a LibreOffice Writer document with the proper layout and existing text?
WCH actually has very good support if you speak Chinese.
It's a pity the datasheets haven't been translated by someone with technical knowledge. I mean, if you look at my
$2 CH551 USB Gamepad project (in Public Domain), they're powerful little microcontrollers, much better than 8-bit Arduinos due to their hardware low/full-speed (1/12Mbit/s) native USB interfaces. (But because I don't know the pin boot-up states, or how strong the pullups/pulldowns are, I had to add current-limiting resistors that make things safe even if exactly the wrong ones happen to be high and the others low during bootup.) That $2 gamepad is designed to have a top carrier with a small 4-wire SPI (well, 3-wire, no chip select) display module, for choosing keys generated by the buttons, or notification from own userspace programs (like mail, perhaps).
In Chinese it means outsiders (as opposed to insiders). I guess it is also correct here.
That's what I tried to find a term for, being outside Shenzhen or China in general, outside the playground with these nifty toys. No racist connotations implied.
If you have something really bouncy, add a holdoff to ignore anything for maybe 50mS after a transition is detected. trivial to do in software
Yep, that's what I do. Even 20ms delay is too long for keyboards and gamepads, so RC filter with that kind of a delay is undesirable, but the holdoff/insensitivity period after transition is really simple to implement, and rock solid. On a 8-bit micro, if you have a byte per button, you can even fine-tune it per button, and still keep a kHz scanning rate so that USB HID reports are sent within a millisecond of the transition. If one looks at their own keyboard usage, having a shorter holdoff period for metakeys for example might make a lot of sense.
Having a button-interfacing dedicated MCU is not as crazy as it sounds, if you design the data interface (uart, spi, whatever) correctly. From keyboard design we already know that autorepeat is best implemented in the device (button-interfacing MCU). While the number of components increases, the software complexity decreases (per part), and we know software is the main source of bugs nowadays. Also, instead of the UI reporting what the buttons/switches/keys have been set to, it should report the state the device is operating on; so, while one is sorely tempted to merge buttons and display into a single unit, that may introduce logical design gotchas one might not think are problems until it is in production, like having button state immediately affect the display. (It's not fun when your display claims the supply voltage is set to 5.0V, the buttons respond just fine, but the main processor has actually crashed while outputting 18.0V)