Are you sure this is the case? AFAIK there is only one active layer at a time. And if not, how do you select multiple layers for activation?
Totally sure, I'm using it (a lot). Unless it's a fork difference, but I doubt it.
Each layer can be on or off independantly, and there's 32 layers because the state of each layer is store as a bit in a 32 bits word.
You can set / unset layers under the current active one without any issue with the normal way, btw.
So if I'm understanding you correctly, you want to take a computer that's set up for AZERTY at the software level, and send it the necessary hardware codes while the keyboard is configured for QWERTY?
Not exactly...
Imagine that I want a Dvorak on my keyboard, where the first character of the home row is A.
When I press the key, I want a A, obviously.
Now, if the computer driver believe the keyboard is a qwerty one, I need to send "2nd key, home row". If the computer believe the keyboard is an azerty one, I need to send "2nd key, upper row".
I want to be able to change this on the fly, having the same layout on the keyboard even if the layout defined in the computer change.
Another way to look at it, if you look at the TMK source code, you don't put a "Q" on your layout, but "KEY_Q", which is a macro that send "the key where there is a Q on a QWERTY keyboard". If you have another layout defined in the computer, you have to import a different definition file.
TMK translate
key ---(layout)--> scancode
I want
key ---(layout)--> character ---(translation table)--> scancode
where the translation table is also switchable on-the-fly.
Could be done by defining the 32 layers for each possible layout the computer may want (AZERTY, QWERTY, etc.), but I'm far from having enough memory for this...
All this come from the fact that keyboard still use scancodes to communicate with the computer instead of unicode points, which is just awfully crude...