Let me repost a comment I made recently:
In some contexts (e.g. Jenkins), a "master" tells the "slave" what to do and the "slave" does it. This at least is plausibly connected to the real-world meanings of the term, although given that the "slave" is free to start and stop work at any time and the entire job of the "master" is to keep track of that, the analogy isn't great. "Coordinator/worker" works well here.
In some contexts (e.g., MySQL), a "master" sends a copy of all its work to the "slave," and both of them execute it. The "slave" stands ready to replace the "master" if the "master" becomes unavailable, and usually at that point the "master" becomes the new "slave" once it catches up. This makes no sense. "Primary/replica" works well here.
In some contexts (e.g., network device bonding, certain types of logical partitioning or RAID), a "master" is a logical construct, consisting of multiple physical "slaves". All interactions with the "master" are actually algorithmically sent to one or more "slaves," and if all the "slaves" are offline, there's no "master" left. This, also, makes no sense. Terms that would make sense include things like "bond/member" (the members being bonded to each other, and the bond being the resulting abstraction), "LV/PV", etc.
In some contexts (e.g. disk drives), the "master" and "slave" are both devices that provide the same type of service to the host, but the "slave" connects to the "master" instead of directly to the host, and while the "master" is communicating, the "slave" can't. The "master" exercises no control over the slave beyond occasionally blocking the communication channel and it pays no attention to communications between the "slave" and the host. This, also, makes no sense. "Primary/secondary" works well here.
In pseudoterminals, the "master" is a limited API to the PTY object, held by the terminal emulator, which copies text to the screen, interpreters rendering commands, and sends input. The "slave" is a more featureful API to the same PTY object, held by the shell / the command under execution, which does what it wants. This, also, makes no sense. I don't know of a standard term here, but I'd sort of suggest "monitor" and "session," which has the benefit of keeping the initials. The M side is the one connected to your actual monitor and it's also the side that monitors output; the S side is the one connected to the application, and it's associated with at most one session in the sense of setsid(2) (see als credentials(7)).
All of these are different uses, and you can't generally map one to another. For instance, if you're used to a database where "master/slave" is used in the primary/replica sense, and you see a database where the "master" just coordinates requests for work and all actual data is sent to/from some "slave," your knowledge of primary/replica architecture is misleading here.
-- In an active/standby replication setup, the master does all the work and the slave just watches and accumulates the results. This seems backwards.
-- In many replication setups (PostgreSQL and DNS work this way) the replica voluntarily connects to an upstream source. Slavery isn't voluntary.
-- In DNS zone transfers, the downstream replica is in control of replication; the upstream can't tell it to do anything. This is not a master/slave relationship either.
-- In a hardware bus system in which any device can be an initiator and can choose its target device, this isn't a master/slave system because the roles change from one transaction to the next.
Having a general ban on the term because of some social pressure to apply "inclusive terminology" is an entirely different issue.
In general, most of the arguments I've seen for keeping the master/slave terms in contexts where they could be renamed without breaking compatibility are for social pressure reasons ("don't give into the mob" / "SJWs are taking over tech" / "free software should be apolitical" / etc.) and not for technical reasons.
And we are debating this, because the fact that they decide to accept to comply with the "inclusive-terminology" movement is going to create a huge precedent, and will actually put an immense pressure on all the other developer community.