Tools don't always need to evolve though. I don't want my hammer to evolve into a screwdriver too, or vice-versa.

Having separate tools for separate things makes sense when the things are different enough.

Yeah but this tool is evolving. You don't get a say on that, this is open source and devs do whatever they want with their time

But I do get to ask why. And that's what I'm asking.

"Tools evolve" isn't a use case. So what's the use case where you need concurrent writes for a database that isn't client-server?

its a file on disk, it relies on the file handling of the OS and an OS file system doesn't give you the same guarantees as a fully fledged db. Even if you try to fix this problem you're just going to end up with trade offs which to properly mitigate you'll end up approaching running some sort of service anyway. At some point you have to ask yourself if jumping through all these hoops has saved you more effort than just running a proper service.

You can justify it as a migration strategy between a file and a service but you're just hammering in screws if you try to force Sqlite to be a multi-client database.

> If there are many client programs sending SQL to the same database over a network, then use a client/server database engine instead of SQLite[1].

[1] https://www.sqlite.org/whentouse.html