Here's a description of how the software can be architected. Just my current visions, everything is subject to change.
I envision a core software system running something like FreeRTOS with an API for module interfacing. The core will handle LCD, SD, buttons, WiFi, USB, timing, and task switching. Each module would have a driver running in a task. The driver task will handle interfacing with the sensor and will output data according to the API. I'm guessing each module task will send a data packet to a queue. Then the core software can handle sending the data to the SD, LCD, WiFi, or wherever.
Each module task could be a loop: send a reading, then block self via binary semaphore. The core software would just unblock that task as needed. Some sensors, like the MCP3424 ADC, take a bit of time to give a reading. They must receive a prepare-reading packet, then have a waiting period, then receive a send-data packet before returning data. If we're running an RTOS, a novice could insert a delay() loop without affecting the rest of the system.
I think the core system wouldn't even care about the module being a single channel or multiple channels of multiple data types. The module would just kick out packets however it needs to and the system wouldn't know the difference.
Output modules, like a servo driver, might be a little trickier to implement. A stepper module and a servo module would probably speak differently and take information from different sources. I wonder how this can be implemented gracefully.