If all implementations use the same code, then they have the same bugs and quirks (and sqlite, being very lite on the SQL standard, has many quirks).
When all implementations have the same bugs/quirks then websites can end up (inadvertently) relying on these bugs, and this makes any future fixes or upgrades to the underlying sqlite very risky (almost guaranteed to break some sites on the net).
It's the situation IE6-only intranet sites ended up with: depending on every dark corner of a particular implementation, and then couldn't even work with IE7/8/9.
So similarly the WebSQL standard would de-facto freeze at some sqlite3 version, and wouldn't be able to upgrade to sqlite4/5/6 until all sites on the web are compatible, which won't happen (and we'd have "quirks modes" for websql versions, etc.)
The whole mess is largely avoided when there are multiple independent implementations. When each implementation has different bugs, then developers will notice that their code works in one browser, but not another, and see what's a bug and what is a feature.
When all implementations have the same bugs/quirks then websites can end up (inadvertently) relying on these bugs, and this makes any future fixes or upgrades to the underlying sqlite very risky (almost guaranteed to break some sites on the net).
It's the situation IE6-only intranet sites ended up with: depending on every dark corner of a particular implementation, and then couldn't even work with IE7/8/9.
So similarly the WebSQL standard would de-facto freeze at some sqlite3 version, and wouldn't be able to upgrade to sqlite4/5/6 until all sites on the web are compatible, which won't happen (and we'd have "quirks modes" for websql versions, etc.)
The whole mess is largely avoided when there are multiple independent implementations. When each implementation has different bugs, then developers will notice that their code works in one browser, but not another, and see what's a bug and what is a feature.