During the firing the version change event (10.5), script may make additional requests. These would keep the transaction alive, so going inactive at 10.6 would not cause the transaction to auto-commit. So waiting for the transaction to finish in step 11 is intentional.

In the case where no requests are made (e.g. your code example), the relevant prose is in the transaction lifetime definition: "The implementation must attempt to commit a transaction when all requests placed against the transaction have completed and their returned results handled, no new requests have been placed against the transaction, and the transaction has not been aborted" The intention is that once we reach a state where all existing requests are completed and new requests can be made, the transaction should attempt to commit.

The statement could be made more explicit e.g. by stating "The implementation must attempt to commit a transaction when it is inactive, all requests..."

Making the whole transaction lifecycle more algorithmic would also be nice. :)

@inexorabletash
Another question here:

10.5 can set the state to finished (by aborting) as in the example below.
step 10.6 then sets it back to Inactive.
At this point, we havent thrown, so 10.7 does nothing.
Since the transaction has been aborted, it is not possible to auto-commit it any more.

Are we now stuck in an infinite loop at step 11?
Is step 10.6 and 10.7 only supposed to run if we are not put into the finished state by the event?

    async_test(function (t) {
        let rq = indexedDB.open();
        rq.onupgradeneeded = t.step_func(function () {
            rq.transaction.abort();
        });
        rq.onerror = t.step_func(function () {
            t.done()
        });
}

Is step 10.6 and 10.7 only supposed to run if we are not put into the finished state by the event?

Yep.

We should add a step after step 10.5 that's basically "If transaction's state is active, then run these steps:" and make the subsequent steps substeps of this. I believe that will handle calling either abort() or commit() during the dispatch, similar to https://w3c.github.io/IndexedDB/#fire-a-success-event

Re-opening, as it would still be nice to have more explicit lifecycle steps for transactions.