In the same area, I am tracking the Rust rewrite of sqlite by Turso [1]. The big advantage is the file format compatibility.
replies(1):
>Our goal is to build a reimplementation of SQLite from scratch, fully compatible at the language and file format level, with the same or higher reliability SQLite is known for, but with full memory safety and on a new, modern architecture.
And they call it rewrite in a recent followup post[1].
[0]: https://turso.tech/blog/introducing-limbo-a-complete-rewrite...
[1]: https://turso.tech/blog/we-will-rewrite-sqlite-and-we-are-go...
Turso a third party project that has nothing to do with SQLite.
A "rewrite" softly implies a replacement (intent that SQLite users would all migrate to Turso eventually & SQLite would cease to exist as a project). This isn't the strict definition of a rewrite but the implication is there in the language.
OTOH the W3C shut down that spec because it required competing implementations to exist. This imagines a world where Turso & SQLite coexist actively.
E.g. micropython isn't a rewrite of cpython even though they both target compatible python, Chrome isn't a rewrite of Firefox even though they both target a range of compatible languages & formats (but Firefox was a rewrite of Netscape - the word depends heavily on context).
I realise this usage isn't coming from you, it's coming from the Turso devs themselves, but it does feel like an overstep on their part.
The Turso guys can use whatever words they like in their blogposts, they're not the authority on whether it constitutes a rewrite.
SQLite compatibility at file level is a nice perk which I am not totally convinced is truly needed at all. Like, it's hard to imagine scenarios where this is useful. But it can be.
Anyway, godspeed. Just don't steal valor.