I don't think simply rejecting out-of-order writes based on sequence number is doable.
First of all, this would be too strict – two operations bound for different tablets on the same server would end up with a false ordering and thus cause them to be fully serialized rather than parallel. We depend on parallelism across tablets even if they're on the same server.
Second, I think there would be issues with leader changes. Imagine something like:
- Client sends seqno 1 to TS A
- TS A crashes and so it doesn't yet respond (marks TS A as "down" in its metacache)
- Client sends seqno 2 to TS B
- TS B receives seqno 2 but hasn't yet seen seqno 1 as a replica
- TS B finishes processing the UpdateConsensus RPC from the now-dead TS A and now sees seqno 1 "out of order"
It can't reject seqno 1 at this point because it's already been replicated.
I'm sure it's possible to get stricter semantics, but I think in most cases even if we provided this, clients would end up producing their own variant of this issue. For example, doing a bulk load using Spark or Impala means that many tasks are writing in parallel, and it's not deterministic who "wins" a race when the same row shows up twice.