Is there a way to have each palm key with the default effect (that is, activate the function layer while held), but to have a new different layer activated while both palm keys are held?
(I could have sworn this was mentioned somewhere already but I can’t find it…)
You could use a MagicCombo. Maybe?
I brought up an idea to use both palm keys together as a way to lock the function layer, whereas used just one at a time, they would do ShiftToLayer, but that’s not the same as what you’re after. It could definitely be done, but I don’t know if it can be done with any of the existing plugins.
I found where it was discussed before - around post 15ish in this thread. It wasn’t ever super fleshed out, though.
Nice. Have you tried it? I’ll give it a go when I get the chance…
Nope, I haven’t tried it. No guarantees that it works. But go for it.
One way to do this would be to put the third layer after FUNCTION, but before NUMPAD, and turn both palm keys into Key_KeymapNext_Momentary. This way when you press one of the Fn keys, you get to the FUNCTION layer. If you keep holding it, and press the other, as that key now goes to the next layer instead of a specific one, you’ll end up on the layer after FUNCTION.
You might have read about it among GitHub issues, because originally the palm keys worked exactly this way, and people ended up on the NUMPAD layer. 
Tried this, and it does exactly what I want. Thanks!
This is a great tool, but it comes with a big caveat. You MUST define at least two layers above the last lockable layer (usually NUMPAD) - otherwise once you lock into that layer you can overflow the layer array on read by pressing the function key(s) - which then returns scancodes derived from uninitialised memory…
Good point. Another option might be to block or redefine the function keys on that top layer so as not to jump above it.
I’m not sure that’s how it works. A blocked key is one that is defined to do nothing. A transparent key is one that is defined to fall through. Neither can be defined in a layer that doesn’t even exist…
Let’s say you defined both Fn keys as layer+1 except on the top layer. When you activate the top layer by any means, if you define Fn on those layers to be nothing, wouldn’t that prevent you from going to an undefined layer? I could be off on my understanding of layer function…just thinking out loud.
Ah, sorry. I misunderstood what you were saying. Yes, if you undefined the layer-switching keys you couldn’t use them to go anywhere.
This works, as long as the Fn keys are layer-lock keys. If you use Keymap_MomentaryNext (the only kind of “next” layer key we have at the moment), it needs to be present on the target layer too, otherwise when releasing it, the firmware would not know it was a layer key. (Or… hm… I’ll have to verify this… it may not be the case anymore!)
In any case, using MomentaryNext needs quite a bit of care. A perhaps safer approach would be to use the MagicCombo plugin.
You would know better… I thought for some reason that when you pressed/held a key on a layer, even if the layer changed, that key definition would remain the same until released and pressed again, at which point it would take on the definition of the new layer.
Yeah, that’s how it should work. But I often “swap out” information from my head, and need to turn to the code to verify if what I have in “main memory” is old or new information O:)
See the thread on stuck mouse keys for all the people who made the same assumption. 
It’s not clear to me what the upshot of the above discussion is.
Do I need to rearrange my layers?
Do I need to block the palm keys on particular layers?
Do I need to switch away from “momentary” to something else?
Right now I have layers in this order: dvorak, function, doublefunction, numpad. The palm keys are defined as momentarynext in the dvorak layer and are pass-through in all other layers.
You will need to either a) define extra function and double function layers above the numpad layer, or b) redefine both fn keys in the numpad layer to be something other than pass through.
This seems like a good argument for including a variable that stores the total number of layers in the sketch file (determined with a sizeof()). That way Kemap_MomentaryNext (and potentially other things) could include a check to make sure it doesn’t read past the end of the array.