You can set the pin to interrupt on either edge:
attachInterrupt (0, wake, CHANGE);
Thanks for clarifying that. I tried it just now, but unfortunately CHANGE doesn't work any better than RISING or FALLING. With any of them, it does occasionally, and seemingly at random, pick up the PllLock interrupt when ListenCoefRx=1 and ListenResolRx=64us. However, it definitely misses the vast majority of them. When I switch to ListenCoefRx=2, though, then it picks up every interrupt just as it should.
The issue is more significant if attempting a low latency listen mode, because there are simply many, many more ListenRx's happening (I'm hoping for 1 every 100ms), and it all adds up. Reducing all those ListenRx's to ListenCoefRx=1 should reduce current consumption by somwhere up to half.
So, plan B is to hope that Listen Mode really does work as it should with ListenCoefRx=1. However, because I can't utilize PllLock pulses which are that brief to wake the atmega328p, I'm hoping that feeding those PllLock interrupt pulses into the atmega328p's asynchronous timer will yet catch them, and thus indirectly wake the atmega328p after a programmed number of pulses are received if atmega328p hasn't already been awoken by receiving a packet while in Listen Mode. Well, that's the theory anyway.
[Edit: Actually, come to think of it, there is one other possibility as to why it's missing most of the PllLock interrupts when ListenCoefRx=1: I have a lot of debug println statements that I haven't commented out yet. Perhaps one of those is getting serviced when the PllLock interrupt briefly fires, and the interrupt flag clears before it finishes with the println's. I'll do some housecleaning and see if that makes a difference. Chances are it might!]