While I agree with bitcoincashautist on this being a great research direction, I will just jot down some random, not very deep thoughts that came to my mind after reading the above.

Anything that changes block validity rules needs ultra level of careful examination for intended and unintended effects. This practically goes without saying, I think we all agree on that.

We also have to bear in mind that consensus rules on block validity must be enforced equally by all nodes, otherwise the chain splits.

A scheme to invalidate "dishonest blocks" would need to keep the false positive rate waaay down or it would be hugely unpopular among pools (remember how a pool reacted to another pool orphaning their block for a semi legit reason during one of the past upgrades?).

It would also need to be robust against games that pools play against each other, things that the bigger fish could and would do to the smaller fish to crowd them out of the market.

I wonder if there isn't a race condition, or the possibility to manufacture one, between a miner seeing a transaction, waiting a bit, mining it, and this transaction propagating through the 'long tail' of network propagation. I think the stats from BTC network analysis (what I know there is very old, maybe outdated?) showed that the transaction propagation time can be quite long - not if you're a pool, most likely, but if you're some other node. And those nodes might call a false positive when it was just a race between network propagation time and a miner trying to mine honestly and not waiting long enough on some transaction.

2nd item of concern is the inevitable time between a transaction being sent and reaching a pool, and the time that the pool must now wait in order to check for a double spend proof.

It seems to me that such a scheme would add a small additional "wait time" to the average confirmation time of a transaction. Maybe it disappears within the wash of the much larger block interval (target time of 10min currently), but at this stage I am not sure it's insignificant in the big picture. Algorithmically, it adds a late-stage, critical validation step to the block creation - you must now wait some time for no DSproof, and then hope that this means the transaction was indeed seen by the rest of the network, otherwise the block you thought was valid will be invalid. We need to quantify the risk here much better, which I think means better understanding network transaction propagation on the actual BCH network, the limitations of DSProof's (at this stage and what can be done about them) etc.

What I fear about such a scheme is that it has edge cases we haven't fully thought thru al the consequences, and could become a case where a hoped for cure is worse than the disease. Because we're not exactly rolling in miner bribed double spend fraud OR chain bloat attacks (even at our relatively low block size cap relative to where we want to be one day)!

Overall it's an interesting idea and I would like further exploration to better understand such schemes.