Litematica: M
MiniHUD: H
and maybe those of other mods wrap some of their hotkeys around a central "entry key"
-> Litematica Config: M+C
-> MiniHUD Config: H+C
-> Item Scroller Config: I+C
this is a very nice design IMO, but if I now have another mod which already occupies M (a map mod in my case) then you need to replace each and every hotkey in Litematica which used M as its entry point. Thus, I suggest to allow some Base Key which can be used in place of a fixed key. By that you could simply update the base key and any chain key which depends on it will update to the new base key automatically! This definitively would be convenient and also mentally supports the "grouping" of functionality behind given keys. Maybe even chained base keys like BK1 + BK2 + C
with BK1 = Litematica key, BK2 = ModeX Key and C triggering the config

This is an interesting idea for sure. But instead of a separate Base Key concept (not entirely sure how you envisioned it), I think it would be better to simply allow "nesting" keybinds, plus allow creating custom hotkeys (which by default wouldn't do anything). Custom hotkeys were already planned anyway since they are needed for some other planned features.

So you could then as a user add a new hotkey, litematicaFooBar and bind that to whatever you want, and include that as part of any other keybinds.

Although to fix your current issue of easily changing the combination without having to do all of them manually, I would then also need to add a litematicaBaseKey hotkey by default already and include that as part of all the default hotkeys which currently start with M.

Well, I actually envisioned it as a reference (key) whose only purpose is to be selected in place of a keyboard press (i.e. referring to other keybindings). So nesting (=referring to other hotkeys) + custom hotkeys as I understand it right now is in fact the exact same solution to that problem! 👍
One of the harder aspects of it will to find a concise, elegant & powerful meaning for "Exclusive" and "Order-sensitive" etc for nested and/or nesting hotkeys.

I think it will likely ignore the settings of the nested key and use the settings of the "outer-most" key, and it will simply take the key codes from the nested keys and use them as part of the key codes list of the outer key.

Maybe you could color code the key codes which are "inherited" from nested keys. That'd directly show what the dependency worked like