Nebuleon

Do you mean that having the user do persistence in `default_layer_state_set_user` (and documenting that method, on top of the `process_record_user` method) would be better than introducing a keycode for it,...

I would update `docs/understanding_qmk.md` with this: ```markdown * [`bool process_default_layer(uint16_t keycode, keyrecord_t *record)`](https://github.com/qmk/qmk_firmware/blob/????????????????????????????????/quantum/process_keycode/process_default_layer.c#L22) ``` but don't know what the squashed commit hash will look like. In that sense, the documentation...

Hmm. QMK CI failure ``` In file included from quantum/quantum.h:40, from ./.build/obj_ducky_one2mini_1861st_default/src/default_keyboard.h:27, from .build/obj_ducky_one2mini_1861st_default/src/default_keyboard.c:26: quantum/quantum_keycodes.h:96: error: "PD" redefined [-Werror] #define PD(layer) (QK_PERSISTENT_DEF_LAYER | ((layer)&0x1F)) In file included from ./lib/chibios-contrib/os/common/startup/ARMCMx/devices/NUC123/cmparams.h:72, from...

And now things should be pretty much OK. I've renamed the keycode to PDF, and edited the original post and the PR title to suit.

This PR now depends on: * #22359 to be merged first so it can work better for layers 8..31. Could a maintainer please add the awaiting_pr tag? Thank you!

Thank you for pinging me, @zvecr. I have updated my branch to current `develop` by rebase, and the conflict in `keyboards/moonlander/moonlander.c` is resolved by following the rename to `keyboards/zsa/moonlander/moonlander.c`.