I'm looking for an answer to a general question. Could we view both thrusters together as a single instrument? Suppose they were wired together using common power and a single serial port. Could it just then (from a software perspective) be a matter of commanding a flow direction (only 2 choices) and velocity? The thrusters are only ever going to be operated in opposite directions. We could even make an option for operating one thruster at a time.  For that matter, they could even be given different velocities.... Just a thought. With our proposed thruster (looking very good, btw), operating as a single instrument could be an option.

Chad
===========================
Neat idea, it's very xFOCE, I think, to consolidate hardware.

The software could likely be written to make the thrusters look like a single device; it could support whatever hardware connections exist, if they are somehow exposed to the application software. 
The converse wouldn't be true of course: can't make them look separate if they aren't wired that way.

To my eye, the big up-sides of combining the thrusters would be 
- Economy of serial ports, and maybe housings, conductors and connectors- all would be big wins.
- Depending on the details, it could also cut the control circuit complexity about in half if the motors shared a controller (at the expense of flexibility).
- It could make the software simpler by consolidating services.

Potential trade offs would depend on the implementation details, but may include

- reliability: 
There would be a single point of failure if the power or serial connection were compromised. 
That said, I think that may be an acceptable risk given the potential simplifying gains. If one motor has a fault, I think one motor is better than no motors. (depends on the implementation).
Does the number of housings, cables, connectors change? Could be great if it reduces the count. 
How would it affect maintenance (smallest field-replaceable unit)?

-  power delivery: 
What does that mean for sizing the sensor node and cabling? 
Are there any issues with the cabling separation or distances from a single point of origin?

- flexibility: a non-issue if the motors can still be controlled separately.

- software and data:
We'd have to think about the software API to this device; what data is produced? how is the device controlled by software?
Would this add (or eliminate) a processor for processing commands? Either way, a big factor (says a software guy ;o)

Off hand, I like the idea of using a single serial port and power connection for water movers.
If we were to go this way, I'd advocate to
- keep the motors separately controllable (speed and direction)
- be fault tolerant (continue running if there is a single motor fault, but maybe OK with risk of single power feed or serial failure)
- run through the failure and recovery scenarios
- not add any processors

Whether we do it or not, potential xFOCEters may like to see our trade table on this.