none of which satisfies my needs.
You have not described your needs.
Biggest problem is the arduino UART taking over the processor while 'communicating'.
No, it doesn't.
any use of these low level protocols is quite 'difficult' for many computer/programmer illiterate.
API issue unrelated to the actual protocols used.
That Sourceforge page looks empty to me.
There's some test framework code, and some .h files, but I didn't see anything about the protocol itself.
the core idea is there.
I couldn't find the core ideas.
YSP_togglePinOnMessage(8, "kitchen.lights.switched")
This looks vaguely like the high-level APIs that BTLE seems designed to address, with its "Services" and "Characteristics." Which it achieve at great complexity, over a relatively high-bandwidth radio links, making a typical BTLE-dedicated microcontroller use 100kB+ of flash memory space. 
we fire a one into space and don't care about the rest ...
If a node detects a signal transmitted, it will copy paste the signal from it's receive pin to it's send pin.
And this sounds like you're after some sort of variably-timed self-clocking data transfer where you send a bit here and there, which everyone else eventually sees and you eventually realize has been sent as far as it will go. A sort of bit-banged ring network. That could be sort-of interesting, but I'm not sure its practical. I'm pretty sure a uart-based serial ring would work a lot better, and that's been re-invented (at least at the bottom layers) any number of times (they wouldn't let me make one for my Senior Design Project back in 1980.)
I think you should step back and more clearly define your "requirements":
There are "network" requirements:
0) type of physical connection. Wire? What type, how long, what voltages, what noise immunity, etc.
- Number of nodes on a network?
- end-to-end throughput requirements?
- Addressing
- Broadcasts? Multicasts?
And/Or API requirements: - do you really want to use text? Who manages what text is "legal"? What happens if someone says "Porsche.headlights.ignited=1" and you don't have a Porsche, and wouldn't want it's headlights on fire if your did
- It almost sounds like, more than a communications protocol, you want a sort of "distributed database" so that all the connected devices know the pin states of each other, and you can do things like:
digitalWrite("BMW.seatwarmer", ON);
and have it work whether or not the box that executes the statement is actually in the BMW. That's not a bad idea, but it can get pretty complicated, and it's also pretty independent of the actually physical layers involved.
the physical layer is ... The signal will be duplicated by all the nodes in the network using the catch-phrase:"it wasn't me".
And... you've gone past the "physical layer."
I key thought to keep in mind with OSI layering is that theoretically, you should be able to replace all the layers "underneath" a particular layer with "something else." Your "it wasn't me" concept is at a higher level than the "voltage levels and etc" that ought to be part of the physical layer.
BACK to the drawing board with you!