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.
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.
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.
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.