I don't have my board handy to provide a proper repro case right now, so I'll do what I can to describe the scenario until I can provide said repro case (and/or crack out my JLINK and just dive in):

• Normally, when stack depth is exceeded (too many nested imports), a RuntimeError is raised (and if this happens in main.py, safe mode should be triggered)

• It appears some cases of deeply nested import trees will bypass the RuntimeError entirely and simply lock the device. After a while, the serial console disconnects, and dmesgstarts complaining that it needs to reset the device, but that the USB device won't respond to addresses (meaning all execution of anything on the device has stopped, probably including the supervisor)

• If this happens in a REPL, a simple reboot of the device (through the button on ItsyBitsy/Feather) gets you back to a safe state. If this happens in main.py, the board is soft-bricked until the internal flash is wiped, which requires a custom build of CircuitPython to be flashed over UF2 that forcibly recreates the internal filesystem, and then another flash of "actual stable" CircuitPython (lest your filesystem be wiped every boot from then on)

Some context:

• CircuitPython 4.0.0-alpha2, atmel-samd SAMD51 (tested against Feather M4 Express)
  • I've also had this happen on NRF52840, based on CircuitPython 4.0.0-alpha1. There's another potential variable at play here, since I'm using my own CircuitPython branch on a non-Adafruit board
• The files in question vary in size anywhere from 2KB to 25KB
• None of the files are frozen into the ROM, they're all copied onto the MSC flash device and compiled at import-time
• Import depth of my worst case was about 9-10 (which is enough to cause a RuntimeError easily)

Also interestingly, updating the max stack size in boot.py does not fix this. Setting the value to anything below 650 results in the RuntimeError, anything over 700 and the modules don't have enough heap space to actually compile (I assume) and fail to import, anything in between and (if I recall correctly - this was a few days ago) I'd deadlock.

The project branch that triggered this is available here: https://github.com/KMKfw/kmk_firmware/tree/topic-planck-klaranck. In kmk/firmware.py I hack around this issue and things work - I believe removing the giant block at the top of the file (everything before Thanks for sticking around. Now let's do real work, starting below) may repro one or both of the symptoms described above when trying to use user_keymaps/klardotsh/klarank_featherm4.py as main.py