In the case of 3, which is by far the most difficult to resolve, the partition tolerance reduces proportional to the duration of the partitioned state, and becomes more difficult to resolve without consequence in any system, as there may be conflicting actions which diverge the resulting state of all partitions further away from each other. These partition events will always become unsolvable at some point, no matter what the data structure, consensus mechanisms or other exotic methods employed, as it is an eventuality that one or more conflicts will occur.
The fact is that DAGs/Tangles and our channels have a better partition resolution performance in the case of event 3 as the data structures are more granular. An inconsistency in P doesn't affect the entire data set, only a portion of it, thus it is resolvable without issue more frequently as the chances of a conflict preventing resolution is reduced.
But afaics they also don't resolve to consensus. There is no rule that forces partitions to merge. Thus they can diverge. Frequent forking is chaos death to a coin.
Now, you haven't provided any detail on exactly how you imagine a data structure that uses blocks that could merge non-conflicting partitions, let alone conflicting ones. In fact I see no workable method to do this with blocks that may contain transactions across the entire domain. Furthermore, who creates these "merge" blocks and what would be the consensus mechanism to agree on them? In the event of a conflict, how do you imagine that would be resolved?
When it comes to partition management and resolution where block based data structures are employed, Satoshi has already given you the best they can do in the simplest form. Trying to do it better with blocks is IMO a goose chase and you'll get nowhere other than an extremely complicated and fragile system.
My helicopter perspective is I can improve on Satoshi. He didn't give us the best we can do. Allow me to think more about the tradeoffs in my design before I reveal it. Also allow me to think about if I can gain any important advantage (for making it a success in the market, not meaning I want to be selfish) by not revealing every detail until I do some more development work on it.
I am still not yet 100% certain that my design doesn't have some flaw that makes it worse than Satoshi's design or not significantly better in some paradigmatic way. I will need to get away from posting and go spend quiet time thinking.
Let me just drop a hint that you appear to be thinking that the temporary intrablock partitions would be using blocks, but I already wrote upthread that isn't the case. The blocks are only for the global consensus that merges the partitions. So I don't use a block data structure intrablock.