Studying @fyl2xp1's own take on the triple buffering problem helped me figure out a way to extend triple_buffer's interface so that expert users can manipulate the data structure more efficiently when they need to, without harming the user experience of those who don't need to care about the low-level details. Thanks for the fresh look, @fyl2xp1!
Along the way, I also tagged v1.0.0 because I figured out there was no good reason not to (people have had plenty of time to submit design feedback, and the remaining upstream issues that I'm waiting for will not have an effect on the API).
So the interface extensions will hopefully be integrated in v1.1.0. After that, I'll need to figure out to which extent I want to propagate those changes to spmc_buffer. Basically, the tradeoff is that in spmc_buffer, allowing the consumer to write into its own buffer is much more costly than in triple_buffer, because there has to be a memory copy involved somewhere in order to avoid a data race between consumers.
EDIT: Also, while I had a look at triple_buffer, found a nasty memory safety bug lurking around in spmc_buffer. Until this one is patched, please refrain from creating an SPMCBuffer<Cell<T>>, which is currently not illegal but should be 
EDIT #2: Fixed in spmc_buffer v0.4.2.