const transition = document.createViewTransition(updateDOMCallback);
await transition.finished;

There are two other promises:

• domUpdated - resolves with the promise returned by updateDOMCallback.
• ready - the transition has successfully prepared, and the pseudo-elements can now be targeted with JavaScript (eg web animation API). It will reject if the transition cannot be ready, either due to misconfiguration, or if updateDOMCallback returns a rejected promise.

I see two possible behaviours for finished:

Option 1: Fulfill on full uninterrupted completion of the transition

If the transition animation does not fully play through, finished rejects. This can happen if:

• updateDOMCallback rejects - a failed DOM update is not transitioned
• A misconfiguration means that, although the DOM successfully updated, a transition cannot be performed. For example, multiple elements have the same view-transition-name, when they're supposed to be unique.
• The transition is aborted due to a newer transition.

Option 2: Fulfill on the 'end state' being visible to the user

The 'end state' being the state after a successful DOM change. This means finished will resolve with whatever happens first:

• The transition plays through to completion
• The transition is aborted, so it visually appears to skip to the end

finished will only reject if updateDOMCallback returns a rejected promise. In this case the DOM change failed, so it does not reach a valid end state.

I originally spec'd option 1, but I've been convinced on option 2, since this is slower in spirit to animation.finished, which will resolve even if the animation is skipped to the end (via animation.finish()).