no, that sounds somewhat right (you need things to be applied, not only acked, so you're looking at extra round trips to communicate that), but that's not a highly available protocol any more as any outage wedges the system. Also, Raft is sort of "too batteries included" to make this work. If you imagined a consensus algorithm that is more modular, you could have
- a failure detection layer
- a (very highly available) replication configuration layer
- the actual replication layer
And then you could configure the replication layer to commit writes only after it is applied (i.e. visible to reads, which implies acked) on all replicas. If a replica fails, you use the failure detection layer to ensure that the failed replica can't be serving any more reads (for example, via a time-based mechanism - note that the replica may be unavailable, but not online, this can happen via network partitions among others). When that's the case, you use the configuration layer to replace the failed replica, and allow writes again.
There are other reasons why this won't work as easily in CockroachDB. One reason is the timestamp cache, which is a data structure that makes sure that writes cannot invalidate earlier reads. This is populated by incoming reads, so if more than one replica serves reads, you have to consistently replicate this data structure, which means you're back to a worse problem than you had initially. But it could work if you only want snapshot isolation instead of serializability (and CockroachDB's guarantees are actually a lot stronger than just serializability).
You can probably tell at this point that this is a much bigger headache than "just" replicating to all replicas. Otherwise, chances are we'd be doing it already. :-)