In the example section there is

// Updates the URL shown in the address bar, as well as the url property. `state` stays the same.
appHistory.update({ url });

// You can also explicitly null out the state, instead of carrying it over:
appHistory.update({ url, state: null });

// Only updates the state property.
appHistory.update({ state });

// Update both at once.
appHistory.update({ url, state });

which seems to indicate that it's not async. There is also the WebIDL format:

undefined update(optional AppHistoryEntryOptions options = {});
undefined update(AppHistoryNavigationCallback);

However, there is one place where it is written with await

use await appHistory.update({ state, url })

But the real reason for bringing this up is to understand better how appHistory.update and the navigate event are intended to work together:

If update is sync, then does that mean event.respondWith() has no effect and you cannot cancel an update with it? Would navigate event handlers need to differentiate between push and update in those cases? Or would it still work and just roll back the update at some future point, possibly firing the navigate event again?

Also, if update and push are different, does that open the door to potential mixups by developers mis-remembering which needs to be await-ed or not? (specifically regarding this section?)

Hopefully my questions make sense, and also I hope I didn't miss a section in the docs that explain this. 😃 Thanks!

(edit: This probably ties somewhat into the conversation happening in #19 as well)