Well, it certainly appears that you have tried enough permutation of device combinations to rule out a problem with a single device. If you had a third NRF24L01 module, you could rule out the (remote) possibility that one was damaged in such a way that the Nano 33 IoT was particularly sensitive to it.
A look at the received data indicates that it is simply correct data where 1 or 2 bits per byte have been flicked to one and, mostly consistently, in the same place. That appears to rule out any byte boundary / byte order / endienness type problems.
Your other options are to:
- Roll back the NRF24L01 library to a much earlier version. Use the library manager for this. If that works, roll forward (using a binary chop type approach) to find out which version introduces the problem.
- Report the issue on github: GitHub - nRF24/RF24: OSI Layer 2 driver for nRF24L01 on Arduino & Raspberry Pi/Linux Devices
EDIT
I could quite easily believe that, since the Nano 33 IoT is a multi-processor device, some special action is required (somewhere) to ensure that, during the usage of the NRF24L01 module, that no other processor interferes with the SPI bus or the pins used for CE/CSN. When the SPI bus was slowed down, for one of the tests, did the corruption pattern appear to change ?