ErgoMechKeyboards

My first ergo split was a Kimiko (roughly the same as a Sofle v2) which also had this num row I quickly stopped using (I ended up affecting it to F keys, still useless anyway; even for switching VTs I tended to use F keys from one of the layers).

My current daily driver is a 3x6 dactyl with a 4th key under middle and ring finger columns and... a 6 keys (2 rows) thumb clusters. All 6 keys can easily be reached because of the 3D shape. I would say only a couple of keys among the 50 are not really useful, hence it is the sweet spot for me now (for a sculpted keyboard anyway; for a flat one, I have to make it work with smaller thumb clusters).

Anyway the similar layout of the thumb clusters and similar goals (Linux user; typing in French) made me want to comment :).

Unless I am mistaken, keyd is a kernel level input remapper (like kmonad and kanata). So it is a lower level component: even if you use keyd, xkb will still be there, downstream. The situation would be roughly the same as with xmodmap... except it won't even be enough!

Indeed, this method consists in mapping scan codes to other scan codes. At this level, there is not the notion that a key produces a character yet. Hence concretely, kernel level input remapping (like QMK, btw) cannot be used to map a key to a character that is not already declared in a higher level component (usually in xkb or xcompose, but it can also be a another component using X11 API, such as xmodmap, for instance).

Edit: to make it more clear, in the end, it is the application who decides what character should be displayed. Typically, for doing so, the application relies on libraries from its toolkit, which implement either X11 or Wayland text input protocols; using standard keycode-to-character translation libraries (i.e., most notably, libxkb). To add new characters in a keymap, these characters need, in the end, to be produceable as the output of these libraries.