I looked at I2C, Serial and SPI. The final choice of ESP12 as SPI master and Arduino Nano as SPI slave is perhaps somewhat non-obvious when you consider that the highest level controller is the Arduino Nano. Here's what I learnt from researching and my conclusions about communication between ESP12 and Arduino Nano for this project.

I2C/TWI

[The Arduino] Wire library has blocking I/O. That means, it goes into a busy loop and waits for the I2C communications to complete. Your application can do nothing while the TWI hardware is talking over the I2C bus. The maximum length of a 'message' is 32 bytes. The time to send just one byte is something in the order of 28 microseconds per byte using the maximum SCL rate of 400kHz (plus an extra byte for address).

Summary: A 32-byte message takes about 1 millisecond, which equates to about 0.05mm for an effector moving at 50mm/sec. I am not sure about the effect of blocking I/O though, when getting GCODE input from either SD card or Serial.

Serial

Nano has only one hardware serial port. Software Serial cannot do the high speeds of the hardware port, and are (I think) blocking I/O. Hardware Serial can easily and reliably do baud rate of 115200 and probably much higher. The Hardware Serial is the default interface to a host computer and using it for interfacing to another microprocessor compromises the ease of host connection. Maybe using the Software Serial for host connection might be workable.

Summary: Technically workable and faster than I2C.

SPI

Maximum speed is the clock speed of the slower partner (16MHz for Nano). Maximum transmission length is 64 bytes of data. NodeMCU does not yet support slave mode SPI on ESP8266. SD card readers typically use SPI, so may need to look in detail at timing for multiple SPI interfaces on the Nano.

Summary: Initially, it seemed obvious for the Nano to be the SPI master since it processes the GCODE and would ask ESP826 to do work for it. However, it might just be better to have the ESP8266 have the SD card reader and be the SPI master sending the GCODE lines to the Nano for handling and getting back the WiFi commands to send to the motors.

Grand Summary

ESP8266 is faster clock (80MHz) so can handle its work 5 times faster than the Nano (16MHz), so how about we load it up with what it can do best. So, the ESP12 can have the high speed stuff of reading SD cards and sending WiFi. That means we use the Nano as slave SPI and does the distribution of work. Perhaps not an obvious choice, but it should be interesting to put together.

PS Comments and any alternative suggestions are always welcome. Even better might be to put together your own project on Hackaday. You'll probably be quicker than me anyway; I am a slow coder.