> ... most of which can be fixed by a rewrite in Rust

huh? That is clearly not the case. memory bugs - sure. Not having a public test suite, not accepting public contributions, weakly typed columns and lack of concurrency has nothing to do with the language. They're governance decisions, that's it.

>I see this situation trhough the prism of the innovator's dilemma: the incumbent is not willing to sacrifice a part of its market to evolve, so we need a new player to come and innovate.

I don't think the innovators dilemma quite applies in the open source world. Projects are tools, that's it. Preserving a project for the sake of preserving it isn't a good idea.

If people need to run a sqlite db in these exotic places, shedding it means someone else has to build their own tool now that can do it. Sqlite has decided that they care about that, so they support it, so they can't use rust. Seems sound.

Projects coming and going is a good thing in open source, not a bug.

Maybe they're saying a rewrite part solves the governance issues not the rust part.

I know I've seen multiple bug reports in open source projects with "well we can't fix this because it'd break things for existing users." Maybe it's a bad thing, but why do you think this doesn't happen?

> lack of concurrency has nothing to do with the language

That's an extraordinary claim for any C codebase.

Unless it ships with code enabling concurrency that is commented out, we should assume that "concurrency in C ain't easy" was a factor in that design choice.