Indeed, as I said— it only gets better.

My most recent thinking is that the best way to drive this kind of technology forward would be to implement a joint transaction system that helps people anonymously make group payments to improve fungibility and decrease transaction costs (using the transaction pattern described here)  using libzerocoin for the parties to agree on who gets paid what.

E.g. N parties show up in a communications group and want to make a joint transaction. They each name an input they want to spend and signmessage for a zerocoin creation showing that they have the authority to spend that coin.  They then return anonymously and provide zerocoin spends that specify the outputs they're interested in. Everyone then knows what the final transaction should look like and they all sign.

In this case the zerocoin part is used to prevent parties from jamming up the mix, e.g. by joining and providing inputs but refusing to sign. If someone refuses to sign— it can only be because either zerocoin has been exploited (and their preferred output isn't in the mix) or because they're trying to jam it.  In any case, you just blacklist their input, and restart the process. Because zerocoin is only used for anti-dos in that context it also means that you could use a faster reduced security instance of it, also allowing some experimentation with the security boundaries.

The fact that the data is slow and big is harmless when its only among a small number of participating parties. This avoids a bunch of scalability concerns, it avoids the reorg risk of an altchain, the network risk of a (soft)fork, the complexity of a global scale decentralized consensus algorithm, allows rapid software evolution because only the participating users need compatible software (vs a blockchain which largely sets the software in stone), etc. but it also puts zerocoin in production use.  The downside is the smaller anonymity sets from small near-realtime mixes but thats also a consequence of ratelimiting a chain based zerocoin.