There is no "work around" for the case of multiple responses to query, you just have to handle all possible outcomes. DALI is designed to allow for collisions which can occur when multiple gear respond to the same query, so you have to handle this in your master software. The slaves must not attempt to avoid collisions with each other - just wait the required time after the query and respond (unless your response is a NO, which is No Response).
There are various cases you have to handle in master software when you expect a response:
No response within the timeout period. All gear that were addressed
have answered NO or were not powered up.
A collision occurs when multiple responses overlap, usually resulting
in bit timing errors. When you only have 2 or 3 gear responding, the
usual case is that the low bits overlap and you end with shortened
high bits, significantly less than the minimum pulse time.
It is possible but rare to have a multiple gear respond with the same
data at exactly the same time and not have any bit timing errors. In
this case you would not know the difference between the response
being from one gear or several. Maybe you can design the system so that you don't care.
It is also possible but rare to have multiple responses align so that
no bit timing errors occur but the response frame is longer than 8 bits. Some gear actually do this by design if they are one hardware unit with several logical short addresses, but the Edition 2 requirement is for this type of design to respond in this case with an extended length low pulse. You should treat either of these as a collision since it is also an invalid frame in terms of what is allowable as a valid response.
As a gear designer, you are encouraged to use the some randomness inside the response timing window so that the rare cases occur as rarely as possible. It has been clarified in Edition 2 that you must not use collision avoidance for the response.
As a control device designer, you need to choose your queries and addressing modes carefully so that you can cope with what the responses might be. For example, if you require the QUERY STATUS bits from several gear, you would query each using its (previously uniquely allocated) short address in turn, rather than using broadcast or group. Alternatively, if you only want to know lamp failure status, a broadcast QUERY LAMP FAIL has the advantage that only gear whose lamp has failed will reply at all, so you might be able to design your logic to deal with a single YES or a collision since that tells you that at least one lamp has failed.