Values of multi-column constraints can be listed out of order here.

For simplicity and for better compatibility with code that relies on old-style messages both constraint and index name can be specified:

if (…) {
    for (…)
        if (…) {
            constraint.getSQL(builder, TRACE_SQL_FLAGS).append(" INDEX ");
            break;
       }
    }
}
…
getSQL(builder, TRACE_SQL_FLAGS).append(" ON ");

getDuplicatePrimaryKeyMessage() also needs to be updated. Something like

        StringBuilder builder = new StringBuilder(64);
        ArrayList<Constraint> constraints = table.getConstraints();
        if (constraints != null) {
            for (Constraint constraint : constraints) {
                if (constraint.getConstraintType() == Type.PRIMARY_KEY) {
                    constraint.getSQL(builder, TRACE_SQL_FLAGS).append(' ');
                    break;
                }
            }
        }
        table.getSQL(builder.append("PRIMARY KEY ON "), TRACE_SQL_FLAGS);

Sure, although I doubt anybody ever care about name of the primary key constraint.
BTW, this @nullable getConstraints()
ArrayList constraints = table.getConstraints();
if (constraints != null) {... ,
gets quite annoying/hard-to-read/error-prone and we have about 16 instances of it.
Would you mind replacing it with @NotNull version returning an empty list, or I am missing something?
It's all DDL statements which are rarely are on a critical path for performance.

return constraints != null ? constraints : List.of() should be harmless, because this method isn't used in performance-critical cases, but H2 uses this logic with null in other methods too and deviation between implementations of similar methods will be surprising.

Speaking of deviations, you mean getTriggers(), sequences, sysnonyms, and getIndexes() ?
They are already implemented with slight differences, and differently from non-nullable dependentViews and dependentMaterializedViews.
I'll be happy to change them all to use gettter() with empty Iterable instead of null.

All existing optimizations were actual for really old versions of Java.

These days constraints can be initialized to new ArrayList<>() instead of null, this constructor since Java 8 (and 7u40) doesn't allocate memory for underlying array and it is cheap enough.

Extra (10-4)*4=24 bytes of array memory (on 32-bit VMs and 64-bit VMs with compressed pointers) if number of elements is between 1 and 4 (Utils.newSmallArrayList() vs default behavior) is also not a big deal.

Maybe Utils.newSmallArrayList() will be better for constraints, because regular tables usually have at least PK constraint and sometimes few others, but I think various temporary tables usually don't have constraints at all.

For sequences with their typical number of elements of 0 or 1, new ArrayList<>(0) can be used instead, this constructor also doesn't allocate array memory for an empty list if 0 was passed to it, but it allocates a single-element array during addition of the first element instead of array with 10 elements.

I'm not sure about triggers, probably new ArrayList<>(0) is the best choice too.

Type.PRIMARY_KEY must be considered as well.

Isn't primary key handled by getDuplicatePrimaryKeyMessage(), not getDuplicateKeyException() ?

Primary key constraints are backed by delegate or secondary index. getDuplicatePrimaryKeyMessage() is only used by the delegate index, the secondary index uses getDuplicateKeyException().

The delegate index is only used for single-column primary key constraints with TINYINT, SMALLINT, INTEGER, or BIGINT data types if PK constraint was specified directly in table definition. In all other cases MVSecordaryIndex is used.

You right, I forgot that, thanks.

This method is not used any more.

PUBLIC.CONSTRAINT_2 INDEX and PUBLIC.ABC (to make sure that names of constraints are qualified).