AVR SPI gotcha
If /SS is configured as an output, the pin is a general output pin which does not affect the SPI system. Typically, the pin will be driving the /SS pin of the SPI Slave. If /SS is configured as an input, it must be held high to ensure Master SPI operation. If the /SS pin is driven low by peripheral circuitry when the SPI is configured as a Master with the /SS pin defined as an input, the SPI system interprets this as another master selecting the SPI as a slave and starting to send data to it.
And then the penny finally dropped - because I wasn't using the default /SS pin it wasn't being explicitly configured, which meant it was in the default post-reset state. The default post-reset state for pins is to be configured for input. That meant that any noise on the pin would trigger the logic that switched the AVR from SPI master to SPI slave mode, and things would apparently lock up, or generally start behaving oddly. It was easy enough to confirm this, I simply configured the default /SS pin to be an output pin, even thought I wasn't using it, and the problem went away.
Moral of the story: When using multiple SPI devices, always use the default /SS pin to control one of them.
Meta-moral of the story: Always re-read the documentation thoroughly when you have unexplained problems :-)
Re: AVR SPI gotcha
"Moral of the story: When using multiple SPI devices, always use the default /SS pin to control one of them."
Isn't the moral of the story actually just always set /SS to an output?
My understanding/experience is that if you set /SS to an output there's nothing wrong with not using it as a chip select pin.