Decided to stick with what I have as adding the extra extender etc etc doesn't add a lot unless we want to use the bottom two rungs in the Zif (pins 13/14/15/16). I'd also need to add an SD module but these all seem to draw a lot of current at 3.3v, more than I was comfortable pulling from the nano and in any case this was starting to drif off from the original motivations. 

The memory restriction was really only apparent if trying to run in "identify" mode with a lot of chips in the list of possiblities. However, this function is not really an aim as stated in the project description. 

It occurred to me that if I wanted to hold the database on the board then rather than putting the data into the sketch like I do now then instead I could store the data in an I2C EEPROM eg https://www.mouser.co.uk/datasheet/2/348/br24t64-w-e-230795.pdf

Of course to program the I2C EEPROM I'd need some it I don't yet have.

Other alternative is to send the chip definitions to a nano from the PC over the serial port using a program running on the PC side. Something like the way this eeprom programmer (https://github.com/oddblk/eeprommer/blob/master/eeprommer.cpp) opens the serial port to send data at the nano.

I actually think there shouldn't be a file system on the tester. It would have to be kept up to date with the library, something that can get out of sync. Rather it would be better if there were a communication protocol that could download test and result vectors from the host where the library is stored. I'm sure it's not hard to implement something like zmodem to squirt the data to the nano. The data isn't huge.

Ah you came to the same conclusion before I saw your full comment.

One way to get a file system might be to connect flash memory using I2C or SPI.

I couldn't find an I2C SD card reader, all seem SPI.
Did you have something else in mind?

I'm currently using D12/D13 for test pins so that interferes with SPI. Perhaps I need another 3rd expander and drive all test pins off three extenders to remove the dependency on the Arduino's data lines. 

The extenders can stay on I2C if I can't be bothered working out a different layout entirely, and a card reader can optionally be on board on SPI.

The current design fits on a 10x10cm board which is cheap to fab on JLPCB, however I just looked and 10x15 isn't much more expensive.

I could take the I2C and SPI lines to a header at the board edge so one can run it from a different device, but also leave space on the board for a nano if wanted. Obviously a complete switch to SPI would be a more consistent approach.

So I'd need to find space for another extender & resistors, plus a card reader and maybe switch to SPI.

Hmm?

Driving from SPI would certainly make the tester more agnostic, usable with more than just the nano. That's quite a rework though.