Thank you all for the comments, links, ideas. That's exactly what I was looking for.

I'm going to do some more reading, and probably have more comments / questions. Would it be better to keep it in this thread, start a new thread, or move to a blog-style conversation, maybe even slap a project title on it? (Newbie to Hackaday here).

My first thoughts as I read what you're written, is that indeed, I'm not going to have more than 26 "instruments" in my Lab, but I'm loathe to "invent" a protocol if there's already one that would mostly fit my purpose, and also I'd prefer to avoid that kind of limitation so I can put "other things" on the network (home automation comes to mind).

I'm grateful for you input, please keep it coming.

Given USB to TTL converters are jellybeans, and TTL serial is available on every uC, why not do a TTL serial based network addressing system? Something like the addressed serial commonly used in RS-485 (note how carefully that was worded RS-485 is only a signaling spec, like RS-232). Very hackable, low latency, fast (over short runs), etc... To make it super easy to use, try to avoid binary data as a requirement? E.g. have a mode where it uses hex ASCII to xfer data and human readable command / address characters. So start with "!" as a command to set a value, "?" to read. Addresses start with "A" (do you really need to address more than 26 devices?

The easy trick is to have each device store and forward each character it receives, but if the address is "A", don't forward until the carriage return, and execute the command. If the address is NOT "A", decrement the address, and just copy through everything until the carriage return. SO the first device on the bus is "A", the second device is "B", etc... on down the stream. Master can send "A?", "B?", etc... to discover what is on the bus. Downstream devices send data to the next upstream device, which increments the address and passes it on. Carriage return ends each command /except/ when binary data is being transferred, in which case the data length must be read and understood by all upstream devices. No bus contention issues, but devices should be able to store and forward messages if they are sending when another device starts sending to them. 

Devices can also talk to each other. Downstream is easy, jif "A" sends down "A?" then "B" will reply. If "A" looks for that reply, it can intercept and not forward. Upstream is harder, the address has to be set below "A" for it to increment up to "A". 

 So "A01,FFFF!" sets register 01 to 65535 on device A, the first one connected to your computer. Register numbers are the minimal interface, other commands should be supported.  How do you know what commands a device supports? Well, "A?" request device information from the first item on the bus. Returned device info can include what commands the device understands other than just register slots and values. E.g. if your power supply is the first device, then "A?" might return:

Power Supply

@ ? Status

V 0-FFFF !? Voltage hex

v 00.00-26.00 !? Volts

A 0-FFFF !? Current hex

a 00.0-10.0 !? Amps

And then you know you can send "A5.00v!" to put out 5 volts and "Aa?" to get the number of amps currently being drawn. Or "A0.1a!" then "Av?" to read the voltage. Or "A@?" might get back "UP" or "DOWN" or "OVER CURRENT TRIP". 

Devices may not support ASCII decimal value setting, so they can use tiny uC's that don't have room for radix conversion. Or they might support binary data (with length) for maximum data xfer speed. But binary support has to be respected by upstream devices. Probably a good idea to include crc in binary data. 

Well, that turned into a book. Sorry... Its just what I would want to see if I was going to have an interconnected set of lab devices. I'm sick of non-human readable, have to write a program to talk to it, proprietary stuff. Debugging and operation are so much easier when you can see the data and it makes sense. 

Key tradeoffs are latency and bandwidth.
GPIB is still worth consideration depending on use case. e.g. GPIB best for discrete DMM as it has minimal latency compared to alternatives (but sure, ethernet/usb just fine for many people). A $5 GPIB adapter design is on EEVblog somewhere.
http://www.ni.com/white-paper/3509/en/
http://www.ni.com/pdf/testsummit/us/Bus.pdf

Some other cool, relevant links:
https://www.eevblog.com/forum/testgear/eez-studio-for-accessing-your-(scpi)-instruments/
https://www.crowdsupply.com/envox/eez-h24005

Personally I'd love to see a universal power supply in a box, useful as a solar inverter (renewable energy inverter) for off grid home use.
TI has an open source design on their website. There are a couple projects on the topic here on hackaday as well. Unfortunately the design is over my head :-)
https://wiki.opensourceecology.org/wiki/Universal_Power_Supply

Great stuff on here :-)

GPIB is a very old protocol.  The only folks that look for it on an instrument are the ones that have an infrastructure set up that requires it.  More modern solutions are USB and Ethernet, but  It depends who your target is.  Some people live and die for a 4-20ma current loop.  If your target is hobbyist than using GPIB would be more of a drawback than a feature (special cables and interface ports-typically usb converters). 

-Bob