What you’re doing is exactly what I was hoping would happen, someone who can program real computers getting nerdsniped into starting a desktop app in a modern language.
You got me there 
Regarding robust serial connection: very good point, I’ve made some changes to jlctl to deal with it there as well.
Now jlctl tries to determine the port automatically. In server mode, if the port gives an error, it re-initializes it. This works well when reconnecting the board, even if the path of the port changes in that process (which it does - at least on Linux - whenever the old port is still “in use” because something has a connection open).
Let me know if that works on Mac as well, I haven’t had a chance to test it elsewhere (jlctl list-ports should list all USB serial ports, and identify two of them as “JumperlessPrimary” and “JumperlessArduino”).
For the measurements, my first thought would just be a call-response setup
Totally fine too - that actually makes it easier to integrate for me as well at this point.
btw, somewhat related to that: the RP2040 supports running it’s ADCs in free-running mode, where one or more of the ADC inputs are sampled repeatedly in a (configurable) interval and written to a FIFO. That FIFO can be used as a DMA read target, so it’s possible to use DMA transfers to shovel those readings into a buffer without CPU intervention. Only once the buffer is full the CPU needs to get involved again and do something with it, e.g. copy it over to a USB bulk endpoint’s buffer, and start the next transfer. Together with some trigger logic (maybe running on the second core?) that would almost be an oscilloscope already.
Anyway, … it’s more of a future idea 
Anyway, here’s the off the top of my head new protocol:
There’s some great ideas in there!
To keep things easy to parse, we could stick with just positional attributes for now (no key/value pairs).
Like:
// set color of net number 8
::lightnet(8, 0x503010)
The netlist could also be split into multiple messages if that’s easier
::begin_netlist
::net(1, "GND", 1, "GND-17", "{GND-17}", 0x493200)
::net(2, ...)
::end_netlist
uart[send] / uart[receive]: I like the idea! Would this be an alternative to having the second UART port, or would both be available and it’s up to the user to only use one at a time?
Extracting the bridges from the netlist is not a big deal, so bridgelist isn’t a high priority for me.
Now that the connection via jlctl is working, I’m refactoring the frontend PoC into something more extensible and less brittle, then I’ll add support for making basic connections in there, to have a first prototype that is actually doing something.
Once I’m there we can think about what to add as a next feature - that also depends on what’s possible with the protocol at that point.
“Single ADC measurement” and “setting node (or net) color” both sound like good candidates.