1. a. made (compiled? interpreted as a script?) by CHDK or they are just passed as-is (.grd contents) to the firmware? or are they written in the frame buffer of the lcd? at all, does it make a difference? i would say yes but maybe i'm mistaken
CHDK parses the file and uses the results to draw the grid directly on the frame buffer. (see core/gui_grid.c)
1. b. if i have, for example, 20 .grd's, can these be changed dynamically or interactively (thru CHDK, with and without menu)?
Not without using the menu. If you are willing / able to hack the C code, that shouldn't be too hard to add. I wouldn't expect such a feature to be added to mainstream CHDK without a compelling use case.
Allowing CHDK scripts to manage CHDK gui widgets is something I'd like to see eventually.
2. well, i looked into it, and from what i understand, the canon menu stays always the same and the chdk menu runs in parallel on-demand.
Correct. CHDK draws directly on the bitmap overlay framebuffer. This is the same framebuffer the Canon UI uses, but the two are pretty much completely unaware of each other. This also means that CHDK displays frequently get trashed when the canon firmware updates.
2. a. can the chdk menu's background be transparent? in all the screenshots i see it black clear now
2.
Yes, the bitmap palette includes transparent entries. That is only transparent with respect to the live view, not other UI elements (canon or CHDK).
b. can the chdk menu take up another appearance than the one resembling the canon settings menus?
The CHDK menu looks like what you see in the screenshots. You could hack it to appear differently in the C code.
2. c. can the chdk menu be hierarchical? e.g. having 4 options on top level, every option taking you in a sub-menu with 1-4 options?
The CHDK menu is hierarchical. See core/gui.c and core/gui_menu.c
2. d. how is the chdk menu built up? is it necessarily baked into chdk or you could have something like an xml parser in ubasic which reads it from the card?
The entire CHDK core is smaller than some XML parsers, we definitely don't do anything like that
The CHDK UI is entirely in C code (see core/gui*), although some things like position, color, on/off state are stored in the CFG file. As I said above, adding some UI capability to lua would be a nice to have (I wouldn't try to do it in ubasic, because ubasic is brain dead)
3. a. so, when i am in live view and i push any button (from the ones on the cross, let's say), it will always send the event to the canon firmware? or does the chdk trap it and (you) decide where to send it?
3. b. in case of "yes, it always goes to the firmware," can scripts only be executed by the chdk menu?
In CHDK "alt" mode, key presses go to CHDK, not the canon firmware. In non-alt mode, key presses generally go to the original firmware. Script generated key presses always go to the original firmware.
3. c. do the button combinations and length of the keypresses depend on the firmware in any way or it's a clean and straightforward system?
It is neither clean nor straightforward. It is a
hack created by pocking binary guts of a completely undocumented system, with minimal insight into how that system was supposed to work, done by many different people with varying levels of understanding and programming ability. You can look at core/kbd.c and platform/<camera>/kbd.c to get a better idea of how it works.
4. what do you mean by custom items?
Without changing the C code, you cannot create new menu items with arbitrary functions
i think i will do some mock-ups to have a clearer view of what we are talking about 
If you want to make sense of this, you will need a camera that supports CHDK. You can pick up an old low end A series for very little.
A very careful study of the source code might also suffice, but even for an experience programmer actually understanding how it all fits together without some amount of trial and error would be quite challenging.
