My quick reading of this is that its suited for databases that don't change much (or at all) once the data is inserted, and not as much for apps that need to keep strong ACID compliance with guaranteed referential integrity.
We handle many thousands of write queries per second at Tumblr, and we use Jetpants to manage our entire MySQL topology, so trust me when I say the data changes quite often :) You can edit your existing posts on Tumblr, unlike on several other prominent social sites.
Definitely please let me know how you got that impression though -- I'm happy to improve confusing things in the docs.
As for ACID compliance: Jetpants is a toolkit for MySQL / InnoDB, and doesn't really impact the referential integrity guarantees of those systems any more or less than other partitioning schemes. MySQL is inherently not a distributed system, for better or worse.
I got the impression because I didn't see any discussion about the handling of bringing new slaves online (other than how to make it fast). Do you pause one of the slaves to get a consistent dump?
Slave cloning is performed by shutting down mysqld on a standby slave and copying its raw data files. There's no dump involved. This is widely regarded to be the fastest possible way to clone a slave in MySQL.
This is explained in the deeper doc files -- didn't want to bog down the top-level README with implementation details.
Meanwhile, data exporting (for shard splits or table defragmentation) is done on a standby slave with replication stopped.
