To be perfectly clear, RS-485 is the electrical signal only. What's transmitted, can be anything. Ethernet, asynchronous serial, synchronous serial, various "self clocking" codes, parallel (e.g. SCSI), etc. OSI layer 1, physical only.
(Funny, I never thought about Ethernet and RS-485 together before, but the signal levels and bitrates are comparable -- 10BASE-T that is. Ethernet is of course an AC-coupled medium, but there's nothing stopping you from using a 422/485 transmitter to drive it, the coding is what controls DC balance.)
Note that RS-422 is the always-on fixed direction (half duplex) version; RS-485 is identical but with transmit enable added, that's all. And RS-232 is a high voltage, low current, unbalanced mode, lower bitrate interface, etc.
So as soon as you're talking about data, codes, arbitration -- you're onto OSI layer 2 at least (link layer). You can do whatever you want with that: you have the RS-485 transceiver's RX, TX and EN pins available for arbitrary use.
Integrated RS-485 peripherals may integrate some of these features as well, which does lock them into particular kinds of links, but automating it as well so you don't need to think about frames, bytes or bits (as the case may be) in software. YMMV.
If collision is detected as RX != TX, note that this depends on line length, because two PHYs right beside each other will tend to drive towards 0V differential, and yield bit errors, but with 10s of ohms of line between them, they'll dominate themselves and not detect bit errors. A more sophisticated PHY with current sensing could still detect this over reasonable distances (indeed, it could perform full duplex service, on a point-to-point link; but multi-drop may not be possible in such a mode), and maybe that's offered by some integrated PHYs, but I haven't seen any standalone chips that offer it.
So it's much better, in general, to have a higher level communication protocol that controls who's talking and listening, to avoid collisions. Handle that however you like: token passing, addressing, etc.
CANbus, solves this in basically the same way I2C does: using a one-way transmitter. Indeed, CAN was invented using a RS-485 transmitter plus diodes. Bus contention is much more detectable when the physical layer has features like this to support it, which in turn simplifies the link layer.
Tim