I agree with Fuseleer it is possible to have temporary partition tolerance, which is in essense what Iota is doing (but I am contemplating that it can be done another way with blocks that I think might have superior qualities). But you still need a global longest chain rule to resolve interpartition activity and thus no unbounded partition tolerance (only temporary). Fuseleer, CfB, and myself all discovered the same conceptual insight.
P.S. I edited my prior post. CfB I also edited the post you replied to.
Sure - partition tolerance I was referring to is the extreme case where an island of connectivity emerges, separate from the main consensus group. Of course there must be a way to objectively merge the two groups together should they be united, and bitcoin's longest chain rule is as good as any model I have heard of.
Correct with regard to your first scenario where 2 partitions never talk to each other in the future, you dont need to consider it. If they do talk to each other in the future, and have to merge, this is where Bitcoin, blocks, POW and longest chain rule falls on its arse. Only one partition can exist, there is no merge possibility so the other has to be destroyed. Even if the 2 partitions have not existed for an extended period of time you are screwed as they can never merge without a significant and possibly destructive impact to
ALL historic transactions prior to the partition event, so you end up with an unresolvable fork. I feel this is a critical design issue which unfortunately for Bitcoin imposes a number of limitations.
CAP theorem certainly doesn't imply you can't ever fulfill C, A and P, as most of the time you can at least enough to get the job done. What it does state is that you cant fulfill all 3 to any sufficient requirement
100% of the time, as there will always be some edge cases that requires the
temporary sacrifice of C, A or P. This isn't the end of the world though, as detecting an issue with P is possible once nodes with different partitions communicate, at which point you can sacrifice C, or A for a period of time while you deal with the issue of P.
If you structure your data set in a flexible enough manner, then you can limit the impact of P further. Considering CAP theorem once again, there is no mandate that prohibits most of the network being in a state that fulfills C, A and P, with a portion of the network being in a state of partition conflict. For example, if there are a network of 100 nodes, and 1 of those nodes has a different set of data to everyone else and thus is on its own partition, the remaining 99 nodes can still be in a state of CAP fulfillment. The rogue node now has to sacrifice C or A, in order to deal with P while the rest of the network can continue on regardless.
All of this can be done without blocks quite easily, the difficulty is how to deal with P in the event of a failure, which is where consensus algorithms come into play.
Bitcoins consensus of blocks and POW doesn't allow for merging as stated, even if the transactions on both partitions are valid and legal.
DAGs and Tangles DO allow merging of partitions but there are important gotchas to consider as TPTB rightly suggests, but they aren't as catastrophic as he imagines and I'm sure that CfB has considered them and implemented functionality to resolve them.
Channels also allows merging of partitions (obviously thats why Im here), but critically it allows a node to be in both states of CAP fulfillment simultaneously. For the channels that it has P conflicts it can sacrifice C or A to those channels, for the rest it can still fulfill CAP.