If one is using SPI to interface two microcontrollers that may spend much of their time sleeping, and if the SPI slave port is supposed to wake up its controller when data is received, that would suggest that the SPI clock wire should not be synchronized to the latter microcontroller's clock. If indeed the clock and processor's clock are asynchronous, that would seem to imply that data written by the microcontroller to its slave port can neither be double-synchronized to the SPI clock [since it must be available to the SPI master on the next SPI clock cycle], nor can it be guaranteed to occur at any moment other than an SPI clock edge [since the SPI slave has no idea when that will be]. The SPI port on e.g. the Freescale KL25 series specifies that if a data underrun occurs, the port will output the previous data, and the next data written by the controller will be transmitted after the repeated data byte. Putting all those conditions together would sound like a recipe for potential metastability issues if the master starts trying to read a byte just as the slave micro is writing it.
I don't know that it would be possible to design an SPI slave port which could guarantee that it would always either repeat a data byte and then put a new byte after it, or else transmit the new byte directly. What can or do SPI slave port designs do to minimize such issues, and what can software in the master or slave do to ensure that they don't cause trouble?