[keithplayer]

I think the HN relevant use case would be looking at this from the opposite side. You've designed 2 games (or algorithms) and both result in a winning state. But when they are used alternately, they lead to worse outcomes. A made up, possibly bad example that's using similar 'rules':

Start with: 1 large fixed size data structure and 1 cache Algorithm A: Checks as it is iterating whether the cache is full. If not, it generates the cache data (SLOW) but can then iterate over the entire data structure quickly. First time it does this is a loss, but 2nd pass through the data structure leads to an overall win. Algorithm B: Prefers an empty cache. If cache is full it will delete it. It can iterate over the entire data structure fairly quickly. Each time is considered a win.

Now you have a program with many different features and everyone knows that it doesn't really matter if you use Algorithm A or B because they are both programmed to work safely together and if you test a feature using one of the algorithms it will be fast either way, so it's left up to personal preference. The fun begins when the full program starts alternating from algorithm A to B.

[hgsgm]

It's a mathematician discovering why we have integration tests.

[Mordisquitos]

Or, from a much more charitable angle:

> It's a physicist¹ proving that we need integration tests.

    ¹ Juan Parrondo is a physicist by training, not a mathematician.