You're right, of course, in that there are such things as package power dissipation limits, etc, which demand that you concern yourself with the power effects of driving many small loads. However, you also have to consider that, when the remote end is powered down, it won't matter much whether your device can "drive" the otherwise unconnected cable. The terminations might be a concern, but, in the event the remote end is powered down or disconnected, the consequence will likely (you have to figure it out for yourself, of course) be too brief to have consequence at the driving end.

A bit of programmable logic at each end might reduce the need for cabling, though I was going to mention that I have occasionally used coax ribbon cable, i.e. a unified flat ribbon of small-diameter, e.g. RG174-sized 50-ohm or 93-ohm cables. Those might allow you to press things up to a much higher throughput and lower latency than putting, say, 40 signals on a single coax and muxing them with your programmable logic.

If the latency isn't a problem, and if the overall throughput weren't a concern, I'd explore the single coax first. Even UTP (Cat6) might be an option with the appropriate PLD. Many FPGA's support LVDS or PECL and other popular low-voltage high-speed signaling options.

Separate ECL transceivers might also be an option if you are using only a single COAX or pair. In such a case, a target-specific adapter board and cable might be just the thing you need, and it wouldn't limit your options the next time such a problem comes around. Moreover, in the development cycle, you can try different approaches to the physical transceiver to see what best meets your needs.

RE