Good topic roach, though its grown fast!
Fuserleer has been working on one for years and has been unable to release something.
Indeed I have been working on it for years, because its a feckin hard problem!
That said I have our solution functioning, I've ran numerous local and small scale WAN tests so far and it all functions well. The next step is a large WAN test, which is what our upcoming Open Beta will provide.
I've viewed information/presentations etc about Eth's proposal for partitioning/sharding and its quite interesting. If you really dig into how they set it up, it seems to apply some similar ways of thinking as my channeled ledger proposals, and applying them to a block chain. That is, no UTXO, instead tracking of "account balances" (which they already have in V1.0) and accounts "living" in a particular partition. They fall short by trying to apply this to a block chain.
I tried a similar approach initially with block chains, and it wasn't too efficient as a block chain's structure doesn't lend itself very well to being "split up", nor would it allow a great deal more scalability in the long term due to propagation. I ditched it after about 3 months of fighting with it and not getting anywhere near the desired performance and went back to the drawing board.
The problem lies with the fact that the blocks contain transactions from ALL the partitions, and so the propagation of the transaction data is not really improved at all. A node at the opposite end of the network that is only interested in transactions within P5 has to wait for that block to propagate all the way across the network, with each relaying node storing the information from it that modifies partitions they are holding.
In the case of Ethereum, the block times are quite short, so its at least feasible that each block only contains information for a subset of partitions. Here though it still can run into trouble as the underlying structure is still a chain, if you have say 32 partitions and the block time is 10 seconds, then on average transaction confirmation times will increase to 320 seconds and beyond. If you decrease the block time too much, you'll find yourself in a network with a lot of orphans being constantly produced.
There are probably other techniques that could be employed to speed up partitioned transaction propagation using blocks, but at the cost of additional added complexity.
With a channeled ledger, transactions are "independent" elements and can be transmitted directly to the nodes that need them, typically within less than 3 hops from the producing node. Nodes that are interested in transactions that reside in P5 will receive them almost immediately from other P5 holding nodes, rather than have to wait for a full block. As there is no mining, transactions are valid and "confirmed" in very short time span (usually instant providing the creator is honest), in the worst case a transaction can be held processing for ~10 seconds until the next ledger state is created if the node processing it has discovered discrepancies.
There is still the matter of the cross-partition problem, and it seems that the Ethereum proposals intend to solve it by way of Merkle receipts and Patricia trees. This approach may be successful, I had a similar solution in mind if the preferred implementation of compact global state using zk-proofs to prove an account has sufficient balance was impossible. It hasn't hit any show stopper problems as yet though, so I've not looked deeper into the alternative solution/s and their implementation.
Fundamentally the main cause of issues with partitioning/sharding is the data structure itself, blocks and chains just do not play nice with partitioning. This is the primary reason why I've taken a different approach, removed blocks and replaced them with independent channels and compact global ledger states that are similar in principle to Ripple's but with the added support of partitioning.
Ethereum is going to have a hard time implementing partitioning on a block chain, and I doubt they will see anything like the 100,000k tx/s that the presentation states they will. The best that my partitioned block chain implementation could achieve was ~1000-1500 tx/s, and adding additional partitions at that point actually slowed it down. I doubt that Ethereum will be able to do much better, and certainly not 2 orders of magnitude worth.