Version 3.6 is definitely after we introduced that functionality. It was, alas, rarely deployed though. Usually clients needed a consultant to put together a configuration for them, and most didn't bother.
There's an option in the Postgres configuration named "track_commit_timestamp" that does this automatically. It's required to be enabled when using LWW as the conflict resolution model. If there's a tie, the node with the highest node number wins.
I don't recall which customer you may have been, but the standard solution to that specific DDL issue with BDR is to use Stream Triggers to enable row versioning. One of the 2ndQuadrant customers used it extensively for multi-region cross-version app schema migrations that could last for months.
Essentially what that boils down to is you create stream triggers that intercept the logical stream and modify it to fit the column orientation by version. So during the transition, the triggers would be deployed to specific nodes while modifications are rolled out. Once everything was on the new version, triggers were all dropped until the next migration.
Spock doesn't have anything like that _yet_, but as you observed, being unable to use DDL replication significantly increases complexity, and tmux is a poor substitute.
You can't even run pgbench unaltered on CockroachDB, as simple table structures and indexes are fundamentally different there. It is in no way a compatible product, and never has been.
In Postgres, updates contain the entire row, including all column values. Since the Spock extension follows the "Last Write Wins" model by default, one row version will win, while the other is essentially discarded. This is assuming the update happened on each node _before_ the new value was synchronized over, or essentially simultaneously.
You can address this partially using a CRDT such as the Delta Apply functionality for certain columns: