Experiment A: fire up a baunch of nodes one way, see how many are marked as BadExit; experiment B: vary the way you fire up on one variable (time-delay, node server Os etc.), measure, repeat
By contrast, being marked as a BadExit due to tampering with content can be due to tests whose exact nature isn't disclosed and changes over time, and it doesn't happen instantly, so it might be hard for an individual deliberately malicious exit to deduce which action it took that resulted in the BadExit flag.
Determining whether nodes are secretly colluding (or, equivalently for some purposes, whether their communications can be closely observed by the same adversary!) is a mostly unsolvable problem, and that's an important limitation for Tor's security. There have been some papers that do a statistical analysis about the probability of an individual adversary winning against an individual user, given some assumptions about that adversary's capabilities (what fraction of nodes the adversary controls or observes). Tor has changed its path selection algorithms a bit based on ideas from these papers.
https://2019.www.torproject.org/docs/faq.html.en#ChoosePathL...
If you're using public Tor nodes, as opposed to bridges, it's not really feasible to prevent nodes from knowing whether they're being used as middle nodes (they can just check whether the previous node corresponds to another node in the public directory consensus).
https://2019.www.torproject.org/docs/tor-manual.html.en#MyFa...
Of course, a malicious relay operator that wanted to increase its chances of being used as both the entry and exit nodes in a single path (and thereby easily being able to correlate traffic between its origin and destination) could add a lot of nodes and not own up to their relationship.
Some people in the Tor community try to watch for relay-creation behavior that they consider suspicious. A common example is a large number of new relays that appear within a short period of time with similar characteristics and don't declare common ownership.
Edit: one of the main tools for this is OrNetRadar, which seems to primarily use the autonomous system number in which the relays are located, as well as the timing of their creation: https://nusenu.github.io/OrNetRadar/
In this case, the relays can be given a flag like BadExit by the Tor developers, which will stop any Tor client from selecting those relays as exit nodes in a path. However, a sufficiently malicious attacker could add a lot of network capacity in a way that isn't recognizably associated as belonging to the same entity, for example by adding nodes in different data centers, with different speeds, with different software environments, and not all coming online at the same moment. In that case, there wouldn't be a way to easily infer that these nodes are associated with the same operator.
As someone has said elsewhere in this thread, there's still the hope that if different organizations add network capacity with malicious intent, they tend to undermine one another's chances of succeeding, at least as long as they aren't directly colluding (because the basic security goal in Tor is that clients choose paths whose constituent relays don't share information with one another).