There is an additional detail that may be worth pointing out and is touched upon by @ideawu in the comment thread on @simbo1905's answer. My answer given below may have been more appropriate as a comment on that thread but I don't have the required Stack Overflow reputation to post comments.
In the classic description of Paxos (e.g. Paxos Made Simple), it is indeed required that ballot numbers/ids are unique to each proposer i.e. no two proposers can propose a value in the same ballot and each proposer cannot reuse ballot numbers for different proposals. My understanding is that this is simply to guarantee that at most one value is ever proposed for a given ballot.
As @simbo1905 points out, one way to ensure unique ballot numbers across proposals is by pre-allocating a disjoint set of ballot ids to each proposer. That is not the only way to achieve ballot uniqueness, though. If acceptors require that the ballot numbers of prepare (Phase 1a) messages they respond to are strictly greater than the ballot number of their latest promise, then this ensures that proposers will never conflict on a given ballot number, even if different proposers try to use the same ballot number for different proposals. The quorum overlap property ensures this, and it is a fact pointed out in Heidi Howard's technical report Distributed Consensus Revised, where, in Section 3.9, she notes (using the term "epoch" instead of "ballot"):
It has long been known that Classic Paxos does not require that epochs
are unique if acceptors require that a proposer’s epochs be strictly
greater than the last promised proposal. This means that at most one
proposer will reach phase two for a given epoch, since reaching phase
two requires a proposer to have already reached majority agreement for
phase one, thus guaranteeing uniqueness.
This supports the idea proposed in the comment above by @ideawu. So, if we ensure this "strictly greater than" behavior for acceptors, ballot number uniqueness shouldn't be externally required i.e. the protocol will enforce it automatically.
Alternatively, if we allow acceptors to respond to prepare messages that have ballot numbers greater than or equal to their latest promised ballot, then uniqueness of ballot numbers for proposals is, indeed, not automatically guaranteed. This fact is, presumably, the original motivation for Paxos requiring global ballot number uniqueness. We can fix this, however, by modifying the protocol slightly. We can add an extra piece of state on each acceptor that stores the identity of the proposer it responded to for its latest promised ballot. If it receives a prepare request from a different proposer for the same ballot, it can reject it. Howard gives a precise example of this in the referenced paper section. This is also the approach taken, for example, in the Raft consensus protocol, where it is implemented using the votedFor variable maintained on each server.
You can see a more formal demonstration of the concepts outlined above in this TLA+ specification, which extends one of Lamport's Paxos specifications to add an explicit notion of proposers. Note that nothing in the specification ensures that different proposers choose ballot numbers from disjoint sets. Here is an error trace (counterexample) that is produced when using the "greater than or equal to" condition and model checking the safety property that only a single value is chosen. When using the "strictly greater than" condition, the model checker terminated without error on a model where the Proposer set is defined as {p1,p2} (two proposers) and Nat (which determines the set of possible ballots) is overridden to be {1,2,3}. That is by no means a proof of safety, but it gives a bit of extra confidence that the reasoning is correct.
