The RP2040 has a single QSPI controller channel, but with clever hacks you can multiplex that to boot from SPI and switch over to some other (Q)SPI peripheral, but iirc you can't write directly (can be emulated via MPU+DMA). What's also quite neat is that you can use the external flash cache as 16kiB SRAM tiled repeatedly over a 16MiB memory window. By abusing the MPU you can allow/trap accesses down to 256 byte granularity and implement virtual memory (allow only one alias address at a time, treat the 16kiB SRAM as a direct mapped cache, and demand page from QSPI, other SRAM banks, or whatever you can come up with).
Impressive work! Of course you can access external RAM, but it comes with some compromises re: speed and usability. Other ARM microcontrollers have a full SDRAM controller on board in its normal address space with very little overhead compared to the internal memory. I'd imagine the SPI RAM here is an order of magnitude slower than the internal RAM, if not two?
edit - that is one WILD codebase... it has both pi pico support but also (remnants of)... Mac OS 9 support!? `#ifdef __MWERKS__`??
Oh, yes, it's a crazy project overall. I would love to see it continue -- I think the Transputer and its OS HeliOS, which is FOSS now -- still has much to teach. But he got it working, so I can also see why not stop digging if you hit the bottom.
Well the RP2040 has a QSPI controller but it has only a single channel that is normally the "boot device". If you bootstrap via SWD (or USB) this device could be at least a QSPI RAM, but writes would have to trapped and implemented in the HardFault handler which is of course very slow compared to internal SRAM. The RP2350 adds a second QSPI channel with QSPI bus (just an additional chip select pin).
TBH I don't know the details of how it works. I am not at all an electronics person. But did you read the article? All I'm saying is that it is possible to add more RAM to a Pi Pico. That, to me, seems to falsify the statement that it can't.