No database in the world guarantees any deterministic ordering for two transactions where the invocation-to-acknowledgement timespans overlap. Such transactions are considered concurrent and even a fully linearizable database can order them however it wants without losing correctness.
In your second example, trxA and trxB are concurrent because at real-world time 9ms, trxA hasn't yet committed.
And therein lies the reason why Spanner waited 7ms. Spanner forced those transactions to become concurrent by making trxA wait, thereby making the anomaly of trxA having a greater commit time than trxB due to clock skew between nodeA and nodeB correct as per the semantic guarantees of linearizability (or what Spanner calls "external consistency").
Had it not waited, trxA's timestamp (7ms nodeA time) would've been greater than trxB's timestamp (2ms nodeB time) even though trxA was acked back to the client before trxB was invoked by the client. This would be incorrect behavior.
In your second example, trxA and trxB are concurrent because at real-world time 9ms, trxA hasn't yet committed.
And therein lies the reason why Spanner waited 7ms. Spanner forced those transactions to become concurrent by making trxA wait, thereby making the anomaly of trxA having a greater commit time than trxB due to clock skew between nodeA and nodeB correct as per the semantic guarantees of linearizability (or what Spanner calls "external consistency").
Had it not waited, trxA's timestamp (7ms nodeA time) would've been greater than trxB's timestamp (2ms nodeB time) even though trxA was acked back to the client before trxB was invoked by the client. This would be incorrect behavior.