I had forgotten that I started this thread. Thanks for the replies.

The situation has changed. After writing this, I did look into the asynchronous model being used by JS. It isn't what I thought it was, but one thing that became perfectly clear is that I wasn't going to be able to solve this in this fashion. The unload event is actually deprecated, and will probably be dropped in some future version of JS. Beforeunload is the preferred event, but it IS intrusive, and despite that fact, it isn't sufficient. I was thinking that the asynchronous model was using threads, which it may in some browsers, or at some time in the future, but at this time that is not the case (and can never be counted on, even in the future). There is no way to pause the current operation and let all deferred promises complete before continuing, and any attempt to do so would introduce a MAJOR exception into the JS execution model, so I don't believe that situation will ever change. JS never blocks, as it stands, but blocking is what would be required.

There are (sort of) ways to get around this in most situations, but not in the situation of the page being unloaded. In that case, continuation is terminal, which means that only blocking would work. The only blocking in JS of any sort is something like the alert, but the JS protocol explicitly states that alert can be ignored in the unload event...which is probably what the beforeunload is all about, but that's a different matter.

So, I ended up re-writing the logic such that it saves all data entered as it is entered. There is never any unsaved data, so there is nothing to be lost by an unload, browser close, or anything of that nature.