If I had superpowers, I would layer the system as a very low-level library that recognizes keyboard / mouse / tablet / microphone input hardware events and encodes them somehow (so Alt is a separate key, pressing multiple keys is handled, clicking + moving the mouse is handled, etc); then a protocol that can give you this event stream, either from a local or remote source; then a layer that maps this into higher-level events (so Alt and Home pressed together is interpreted as Alt-Home). The idea would be to have the ability to detect, even over a serial connection, any of these input events, without resorting to escape codes.
I don't even know if this all makes sense; I just hate the loops you have to go through today to even try to make sense of key combinations.
/rant
Since tty's are fairly well married to a serial port, adding an ioctl() (or similar) that would switch channels would seem likely. RS-485 would provide a way for that to work not just with ptys, but with real physical devices as well. With reasonable backward compatibility.
Ethernet as it is typically deployed is not a bus either but it is used in channelized communication (packet switched no less) just fine.
Edit: responding to your edit. The point still stands this is orthogonal to the physical or electrical layer. The vast vast majority of the internet including Ethernet and fiber links are point to point and clearly they carry a tremendous number of separate streams, and a small amount of broadcast. You can run layer 2 over an RS-232C serial port, whether its Ethernet, PPP, SLIP or ATM. In Linux PPP is in fact implemented as a tty line discipline.
As for RS-485, there are widely used standards such as DMX512. It is not a strongly supported idea to put this stuff in the kernel, when performance in user space is sufficient.
Finally, RS-232 can do the same thing (multidrop) with electrical repeaters. See MAX3322 eg.
As others have said, RS-485 isn't really the way to do this. It looks like RS-232, but it's just close enough to mislead you while being far enough away to be a total nightmare. For example, any bus collisions have to be handled in software. A driver that has to recognize and deal with bus collisions looks very different from one for a dedicated line.
This rabbit hole is probably not worth going down.
All the stuff you mention like collisions and addresses and shit starts to be layer 2 and above.
RS-485 is an electrical signaling standard, for carrying arbitrary bytes between a transmitter and a receiver. There isn't even any built-in concept of a packet, let alone an addressing scheme. It's no different than RS-232 at all, in that respect.
When compared against RS-232, only the signaling voltage and impedance requirements are different. That, and also RS-485 has no standardized connectors or side-band signals (like CTS/RTS).
Sometimes RS-485 is used half-duplex over a shared differential pair. In situations like that, slave devices are often designed to keep their transmitters disabled unless responding. Sometimes, these setups will have a couple of devices listening for data.
Lots of people implement custom bus protocols _over_ RS-485. But RS-485 by itself has no concept of buses, packets, addressing, channels, slave devices, or master devices. It's just an electrical signaling standard. Nothing more, nothing less.
It's kind of like saying "AM radio-waves are a format for carrying music". Sure, some people transmit music over AM radio. But that doesn't mean that the actual radio waves have any knowledge or accommodation for what they're carrying.
You may be mixing this with Modbus which is typically run on RS-485.