Of course. To check that cloudfare sends your website the same way to various IP address, you (or someone who you trust) need to have either physical access to that requesting IP address, or remote one. This is not my assumption, misunderstanding, or misinterpretation, this is just how internet works. Speaking of particular ways of checking remote access, the three I mentioned were the most obvious examples (and they often can be checked even without being cloudfare and without controlling the outgoing traffic from your various IP addresses), but cloudfare definitely had more time to think about this detection as well as much more data to analyze, including the outgoing traffic. This way they can check the computer knowledge level of the users at that IP as well.

Again, this is wrong. The price of a "false negative" result of a check by cloudfare (they think you are checking them for spoofing, while this was a third-party user trying to mix his or her bitcoins) is just that they miss the tracking of this particular user and will not be able to reprt him or her to the authoriries in the future. This will not prevent cloudfare from tracing and reporting other users.

And the price of "false positive" (you are checking, but cloudfare doesn't recognize you) is not too bad for cloudfare either. At worst, they will lose your webiste if you decide not to use their "ddos-protection" ever again (and even this you don't say, you just say "automatically shut down the clearnet version", but you don't say how long you are going to keep it down). As for the other webistes they MITM/"ddos-protect", your observation of spoofing will not really have much effects with cloudfare's already-terrible reputation. And for your users who already mixed their bitcoins, it will already be too late.

So, 100% accuracy is not necessary for cloudfare. Even 30% false negative with 0% false positive does not contradict the observations you say here, in this thread.

Where did you say it's temporary? If it's temporary, then: as long as you collaborate with cloudfare, this continues to be a battle of shield and spear at best, for all of the period you use cloudfare.

I agree with this. But I don't think it's a good reason to introduce one more attack vector. You could disable https altogether with the same reasoning.

If your server is not on-premises, this is one more attack vector, yes.

A side-remark is that if there is no tampering with distribution of the tor address of your server, and there is no tampering with distribution of tor browser itself, then this is as secure as your own open-source app.

It is possible to organize an attack that will allow cloudfare to know the connection between a certain percentage of incoming and outgoing mixing transactions, even if not all of them.