> can we call it `addDeletedOrLocalIndex` (similiarly with the websql migrations, the version logic is kept here, so the migration function can have a descriptive name 

Sure, the name isn't a big deal, it's just my habit from Liquibase migrations in Java (where it'd be something like `002-add-deleted-or-local-index.xml`).

>and not so much a review, but what happens with indexeddb and async schema migrations? I am assuming here the cursor waits for the .put to loop, but runmigration2 is gonna complete immediately and if were were to have runmigration3 are we just using the assumption that runmigration2 will have a running transaction blocking it? 

Yeah, good point, when migration3 shows up, we'll have to have some extra logic to chain them together sequentially.  I planned that users starting from zero would run the same setup script that would implicitly run migrations 2 through n, but for everyone in between, it's much easier to just run each individual migration function sequentially. So yes.

> Also what happens with async non idb requests, like xhr / blob stuff, are they just straight up not gonna work?

Technically we have the same problem with the setup function no matter what, right?  Since IDB's constructor is async, there's always the possibility that someone will try to run a function on it before it's ready.  Which is I guess why using the promise form of `new PouchDB()` is preferable to the synchronous form.