This approach looks cleaner for me too, but, again, what about other DDL commands?

In this branch there are about 28 calls to session.commit(true) in org.h2.command.ddl package. Are these calls still needed? With your changes here session.commit(true); is called twice, first time in Command.executeUpdate() and second time in the update() method of executed command (AlterIndexRename, AlterSchemaRename, AlterTableAddConstraint, and so on).

Ok, I got your point now, and it looks even messier than before. I was checking all access to transactional / isTransactional() (and even then I've missed AlterTableAddConstraint), but majority of those commands just always call commit() without any checks, assuming it's non-transactional. My bad.
Probably in a majority of those cases, being "outside of a statement" is not a big deal, due to their short-lived actions, but AlterTableAddConstraint can build potentially huge index and cause crash.
Will try to remove those commits at the beginning of update(), since they should be redundant with latest changes, anyway.
Most problematic here is RunScriptCommand where containing statements are executed using Prepared level instead of Command flow. Will try to lift it there. Still unsure whether forced commit (at the beginning and at the end of non-transactional statement) should restore auto-commit mode or preserve possible manual commit mode.

Still unsure whether forced commit (at the beginning and at the end of non-transactional statement) should restore auto-commit mode or preserve possible manual commit mode.

From my point of view all DDL commands should preserve / restore the previous auto-commit status on their completion. Users don't expect it to be changed anywhere.

But we also have an undocumented BEGIN [ WORK | TRANSACTION ] command for compatibility with something; that's why you need that weird condition in commitIfNonTransactional().

I don't think that new assertions in update() methods are really useful, but otherwise everything is good for me.

I don't think that new assertions in update() methods are really useful,

Agree, it was just a quick way to verify my assumption.

The unusual failure in TestCrashAPI doesn't look like being related, I filled a separate issue about it.

@katzyn, If you say so, because I am not 100% sure. Unfortunately I can't reproduce it, might be JDK-dependant.