If your definition of "consistency" is "read will always returns the latest value which is accepted by all nodes in the first phase" you'll always have to contact all nodes when you're reading the data (since as you mentioned you can't actually depend on if it's been "committed"). This is "CP" because you "tolerate" a network partitioning by having the read return an error if it can't reach all nodes.
But you can "tweak" your definition of "consistency" to be "reads will read the latest committed value on that node". CAP still applies for the system as a whole (with writes), but now you can serve fast reads from a single node.
Many systems defines "read consistency" as "snapshot isolation" which means (roughly) that all requests inside a single transaction will be executed against a single snapshot (which possibly isn't the "latest" one). This will also allow you to execute reads against a single node.
And to quote the two authors who actually proved CAP, Seth Gilbert and Nancy Lynch. (Emphasis mine):
> Consistency, informally, simply means that each server returns the right response to each request, i.e., a response that is correct according to the desired service specification. (There may, of course, be multiple possible correct responses.) The meaning of consistency depends on the service.
> Please don't post shallow dismissals, especially of other people's work. A good critical comment teaches us something.
The main thing I'm disagreeing with is undefining what CAP means. CAP is a very particular proof and the rest I think perhaps we need a new name for.
> CAP has a long history and was originally provided without a proof.
Irrelevant. All of database history is filled with what today is comparatively junk. The understanding has improved and we have better ways of talking about the particular subject matter.
> The proved version of CAP has a very strict definition, but it's not that useful in practice because most systems don't actually follow that model.
It is useful in what it proves, so don't bend the definition. This is my main point. You will have to invent another taxonomy perhaps. We have good names for all the typical consistency models I believe, so we can use those as a starter.
> Most notably, the CAP theorem is often still true when "consistency" is defined as weaker than "linearizable".
This is the type of reasoning that just muddies rather than clarifies.
If the coordinator crashes, one (or all) of the transactions will be stuck until the coordinator comes back - or, if it never does - until someone manually rolls them all back of commits them all.