Consider the following case:

CREATE TABLE t (i INT PRIMARY KEY);

SET use_declarative_schema_changer = unsafe_always;

BEGIN;
ALTER TABLE t ADD COLUMN j INT NOT NULL DEFAULT 30;
ALTER TABLE t ADD COLUMN k INT NOT NULL DEFAULT 40;
COMMIT;

The first ADD COLUMN stmt will build, plan, and execute the statement phase. (no problem!)

Then, the second ADD COLUMN will build, and plan from the state reached after the
statement phase from the first ADD COLUMN stmt.

That plan looks like this.

There are two issues spotted from that graph:

1. Recall that the basic idea of ADD COLUMN is to create and backfill a new primary index, and finally swap it with the old primary index. However, because we had two ADD COLUMN stmts, the graph shows three primary index element (the original one idx1, the one created for the first ADD COLUMN stmt idx2, and another one created for the second ADD COLUMN stmt idx3). This is not expected though -- we'd like to modify and reuse idx2 when building the second ADD COLUMN stmt.
2. In the stmt phase of the graph, idx1 -- the original primary index -- transitioned from PUBLIC to VALIDATED as a result of the MarkDroppedPrimaryIndexWriteAndDeleteOnly. This is incorrect as we should only turn idx1 to non-public when we're ready to do the primary index swap, which happens after the new primary index (i.e. idx2, assuming issue 1 above is fixed) has been backfilled, merged, and validated.

Jira issue: CRDB-16799

Epic CRDB-31472