Electronic – How to configure the FTDI FT220x for multiple SPI slaves

"An introduction to asynchronous circuit design" by Davis and Nowick (in particular, Figure 1 and Figure 2 and the nearby text) describes two handshaking protocols as "pervasive". The 4-cycle protocol, aka RZ (return to zero), 4-phase protocol, and level-signaling. And the similar but more complicated to implement 2-cycle protocol, aka transition, 2-phase, or NRZ (non-return to zero) signaling -- which is very similar to the "data strobe encoding" used by SpaceWire and FireWire. Either one sounds like it has most of the features you requested -- it's SPI-like in that there are exactly 4 signals, all 4 signals are one-way (no passive pull-ups), the master can pause the slave indefinitely until it is ready for the next bit from the slave, etc. It also has a feature supercat requested that SPI doesn't have: the slave can pause the master indefinitely until it is ready for the next bit from the master.

I don't know of any chips that have the 4-cycle protocol built in, but it looks like it would be easy to bit-bang on a microcontroller or a CPLD. In fact, it looks like it would be easier to bit-bang than SPI, since (like SPI) the master has no timing requirements, and (unlike SPI) the slave has no timing requirement either.

Is it possible to use the 4-phase protocol for synchronous bit transfers, and somehow build a higher-level protocol on top of that to get the other things supercat wants -- byte alignment, start-of-command frame alignment, attention/busy/idle states, etc?

SPI allows the so called "Daisy-Chain" and multi-slave topology. You seems to need multi-slave. Note that altough you will need a separate signal for the CS pin of every chip, you can share the MOSI/MISO/CLK pins between your nodes.

For your parameters, I think that a proper routed board will suffice since you are not working at high clock/signal speeds.

I never heard of SPI pins being terminated. You must indeed take care of grounding and avoiding short-circuits.

Note also, that I2C looks like a more appropriate solution for connecting several devices in a BUS (altough with less speed).

You can have your setup like this:

HOST_MOSI -> DEVICE1_MOSI, DEVICE2_MOSI, ..., DEVICEn_MOSI
HOST_MISO -> DEVICE1_MISO, DEVICE2_MISO, ..., DEVICEn_MISO
HOST_CLK -> DEVICE1_CLK, DEVICE2_CLK, ..., DEVICEn_CLK

HOST_PIN1 ->DEVICE1_CS
HOST_PIN2 ->DEVICE2_CS
  ...
HOST_PINn ->DEVICEn_CS

You might want to read link 1.