Turns out that insertID is *really* hard to get right :(

Can you clarify? Is the problem that you don't know after a single call to ExecuteStep whether there will be subsequent steps required, so you can't satisfy the "ID of the last row" constraint? It seems like you could just populate insertId from a call to sqlite3_last_insert_rowid and rowsAffected from a call to sqlite3_changes. Update the values on the mozStorageResultSet each time before you dispatch it to the origin thread; the insertId value will become correct when execution completes.

Er, actually, INSERT/UPDATE/DELETE run to completion in a single step. Things should be correct immediately, so I must be missing something...

You cannot trust sqlite3_last_insert_rowid when you use multiple threads unless you protect the database connection with a mutex. In our situation, protecting it with a mutex would be really difficult.

We could probably use sqlite3_update_hook, however. My only concern is what happens when someone runs something on another thread while we are running? We'll get a callback for something that isn't ours. :( We could add a warning that results are undefined when using a combination of the async and sychronous api (we do this elsewhere). See http://www.sqlite.org/c3ref/update_hook.html for details.

Per policy at https://wiki.mozilla.org/Bug_Triage/Projects/Bug_Handling/Bug_Husbandry#Inactive_Bugs. If this bug is not an enhancement request or a bug not present in a supported release of Firefox, then it may be reopened.