I don't know anything about this and the flame/troll aspect of the thread makes me not want to. I was kind of hoping that a new Lisp on a new platform might have a chance at a fresh start clear of all that stuff.
I did notice one thing, though. Assuming that what Rich Hickey's saying is true, it would be better to point to something visible that the demo does that the knockoff can't do. If it's possible to appear to reproduce a demo without doing the hard parts, then maybe the demo wasn't actually demonstrating the hard parts. In that case a better demo would be a good idea. Such things can be hard to come by, though, as demos tend to be relatively simple and thus knockoffable.
This locks vs. STM debate is a lot like the old malloc vs. GC debates. "Look at my fancy new Java code. I just do foo = new Foo(); and everything is taken care of" and then a C++ guy responds with "so? I can do foo = new Foo(); delete foo; That's only one more line than your fancy GC system. My version is also faster because it doesn't waste time on GC".
Locks vs. STM will play out about the same way. It's hard to demonstrate all the things you don't have to care about with GC. Making a good demo that shows you don't need to worry about memory leaks, double freeing, memory corruption, etc is hard. The same is true of making a good demo for STM that illustrates all of the problems you don't have to worry about compared to locks.
I think the ants demo is a good idea technically. Now it just needs a set of "rules", similar to what Rich just posted.
It may be that there isn't a program that's both complex enough to make the problem visible and small enough to count as a demo. In that case, it might be better to call it a sample.
If it were my demo I'd focus on making the value visible. For example, if the value is correctness, then make it obvious when the state becomes incorrect. An incorrect program ought to hit this if it runs long enough.
I did notice one thing, though. Assuming that what Rich Hickey's saying is true, it would be better to point to something visible that the demo does that the knockoff can't do. If it's possible to appear to reproduce a demo without doing the hard parts, then maybe the demo wasn't actually demonstrating the hard parts. In that case a better demo would be a good idea. Such things can be hard to come by, though, as demos tend to be relatively simple and thus knockoffable.