This may be the blind leading the blind...
I think the key is that this is not automatic -- there is no general
mechanism for aggregating distinct modifications. Point being that you
could choose one amongst right answers, but not what to do with
concurrent modifications. So what is done instead is have
application-specific resolution strategy which makes use of semantics
of operations, to know how to combine such concurrent modifications
into "correct" answer.
I agree with all of that.
I don't know if this is trivial for case of
counter increments: especially since two concurrent increments give
same new value; yet correct combined result would be one higher (both
used base, added one).
As long as the conflict resolver knows that two writers each tried to increment, then it can increment twice. The conflict resolver must know about the semantics of "increment" or "decrement" or "string append" or "binary patch" or whatever other merge strategy you choose. You'll register your "strategy" with Cassandra and it will apply it. Presumably it will also maintain enough context about what you were trying to accomplish to allow the merge strategy plugin to do it properly.
That is to say, my understanding was that vector clocks would be
required but not sufficient for reconciliation of concurrent value
I agree. They are necessary, but not sufficient. The other half is the "merge strategy plugin" thing, which is analogous to custom comparators in Cassandra today.
In CASSANDRA-580, Pedro Gomes talks about the plugins like this: "I suppose for the beginning of the discussion that some sort of interface will be implemented to allow pluggable logic to be added to the server, personalized scripts were an idea, I have heard. "
Kevin Kakugawa replies that they'll just use Java class libraries as a first pass.