This is a very classic problem in networking and has been solved in a myriad of ways. Assigning addresses is common. Each slave would have some way of being assigned an address. In many industrial networks, this is something like a DIP switch. There are also automatically configured network who get an address at start up or on demand. This often involves each slave having a way to block any downstream traffic, respond themselves, accept an address, open its downstream port and let the next downstream slave do its thing while it remains quiet. Often these downstream switches are relays that drop out without power so that let the signal flows through on an unpowered node. Once everyone has an address in either system, the master polls each address. One of the downsides of this is that if a node drops off and then returns, the string has to be reconfigured- this can take some time because of all the nodes and the necessary timeouts, etc. A twist on this is to use a 9 bit scheme on your uart (many do this or you can use parity and manually set the parity bit). Only the first message that address a new node has the ninth bit set from the master. This allows the slaves to ignore all message traffic until another ninth bit interrupt occurs. This is a pretty good system but you can imagine places where it will fail. Stuck nodes and dead nodes is one first order problem.
More sophisticated systems like early ethernet used carrier sense multiple access with collision detect (CSMA-CD). Wikipedia explains this better than I can but in brief it involves checking the bus for activity and not transmitting if there is stuff on the bus. Coupled with this is collision detection system because two nodes could choose the exact same moment to start talk. This requires messages to have checksums or CRC codes embedded to tell if the message got clobbered- on some busses like 485, you can read back what you sent in the common half duplex case. Often there is a random back-off after a collision so the two don't just fight each other forever. This works well if the bus is fairly lightly loaded- you have short messages and a fast medium. As the bus gets busier, its harder for anyone to find a slot and the collisions increase and the whole thing falls apart. You can also have a stuck node that just keeps talking and can take down the bus. Various schemes have been used to fix these issues.
IBM networks and some industrial networks use a "token" passing system. There is a token- a permission command- that is passed around and the node with the token can talk and then relinquish the token. This can be pretty efficient but provisions have to made to create a new token if it gets clobbered (usually with a timeout). This can all be masterless, ie peer to peer if the token is passed from node to node and instantly relinquished if not needed.
Still other systems uses things like TDMA where each node is given a time slot that depends on it address. If it has something to send, it waits for its slot and sends otherwise the slot goes unused. This has the disadvantage of wasting bandwidth but is robust and deterministic if all the nodes talk pretty often.
You can also have protocols like CAN where the address with the most zero's (or 1's) wins, If the bus is open collector- like, the node that pulls the bus down with the most zero's will win. This kind of creates a priority structure for the nodes. This takes a bus like CAN that has dominant and recessive states. Cars and a lot of industrial system uses CAN. This is just the PHY layer of CAN, CAN is also a protocol. Some industrial networks use the CAN protocol running with RS-485 phy's- some industrial fieldbusses.
Cars have several networks these days- Fly by Wire- steering and brakes use protocols like Flex-Ray that is completely deterministic at the cost other things. Drivetrain systems often use CAN bus which is very robust and expandable. Body electronics can use low Speed CAN, single wire CAN, LIN or other simple one wire protocols that don't require much sophistication in the nodes (a window button cluster). Mutlimedia in cars use a variety of protocols like MOST or MOST over copper. Increasingly Ethernet is finding its way into modern cars especially for streaming and infotainment.
Do some web searching- this is well travelled but interesting ground and a lot of clever solutions have been put together. Like all of engineering, each solution has its tradeoffs, in efficiency, bus utilization, determinism, software or hardware simplicity, robustness, etc. A very rich topic worthy of some study.