But there are multiple competing implementations of GIF, JPEG, and thousands of other image file formats, and the browsers vary in exactly what code they use. Browsers actually DO use multiple TLS/SSL stacks (NSS, BoringSSL, OpenSSL at least), and multiple implementations of tons of protocol components (like compression) are around as they need to test things like performance. Multiple implementations of e.g. WebRTC exist. You could replace any of these components with a completely different implementation with relative ease, because other implementations do, in fact, exist.

Furthermore, outside of the TLS case, most of those are still within the ballpark of reason -- feasible to reimplement even in a small group. That's definitely something to be considered -- it's not just a case of if it's possible, but whether at all it's even realistically feasible for most people to reimplement.

Replacing WebSQL is on a completely different level of difficulty compared to these. Not only is it massively more complex to implement, there really is only one implementation, so it's pretty much impossible to reimplement exactly to spec, with the same kind of performance/usability characteristics -- without just doing a clean-room analysis of SQLite.

> If SQLite gets new features you do the same thing you do with other specs. If it makes sense to expose them, you update the spec.

It's never that easy. What happens if SQLite changes the way a feature behaves, even for good reason? The developers aren't beholden to browser devs, so this is within their right. What happens if they don't change something and a bug is then "enshrined" as part of the implementation -- or what if someone wants to make a change like, I dunno, actually checking the types of values you insert into the DB?

I do think WebSQL was promising and it does suck it was axed. But I think it was axed for a fairly sound reason, even if humans aren't always perfect robots who make exactly perfect decisions in similar instances (e.g. a similar difficulty argument could be made against TLS, although we're already waaay past that point).