I'm not sure it ever will.

The primary use case of this branch is to make SQLite into a more "client/server" like architecture, which deviates from the predominate target use of SQLite (embedded).

Though I too would love a client/server version of SQLite.

I'd put it more at "multi user" rather than client/server. I'm confident that that goal will never be acceptable reasoning for any changes or improvements to the code.

I’d still say “client/server” because:

a. SQLite, by default, doesn’t allow multiple writers.

b. There’s also real challenges to writing to a non-local (network) filesystems

https://www.sqlite.org/useovernet.html

For sport I'll counter with:

a. SQLite, by default, does allow multiple writers to connect, but only one can write at a time.

b. NFS was never suggested to be used -- embedding it in an app that exposes a network api works fine.

c. The behavior being discussed (multiple concurrent writers) already kind of exists (multiple writers) and this would just make them more performant.