One thing I never understood is why there needed to be a second implementation of WebSQL. SQLite is public domain, any browser vendor can choose to embed it in what they ship.
It's a standards process requirement. A standard must have a well-written spec, well-written enough that multiple implementations are possible. Showing multiple implementations that are compatible is enough to prove that.
When there is just a single codebase, even if it is open source, it isn't a standard. Now, not everything needs to be a standard, but on the web standardization is a big part of why it is so successful.
One example of why a single codebase is bad: Imagine that SQLite version X is the implementation of WebSQL, which all browsers must use. SQLite development is of course continuing, fixing security issues and making it faster, etc. Will browsers just keep using SQLite past version X? What if the SQLite community takes SQLite in a direction that isn't optimal for web browsers? Perhaps web browsers will fork it. What if browsers end up not agreeing on the fork, and some use the original project, and others use the fork - or there are multiple forks?
All of that makes it very risky that compatibility issues will appear between browsers. Having a properly specced standard, with multiple compatible implementations, is so far the best way that we have found that can prevent such things.
More succinctly: SQLite version whatever is specified only by its C source code, and C is woefully underspecified. Lots of Undefind Behavior on top of the memory-unsafe codebase itself. This is not a specification from which two independently implemented interoperable implementations could be written. Ergo, not a standard.
