I've still not found anything as easy and complete, feature-wise, as fossil. What is jj trying to solve over git, assuming it's more a replacement for git.
It's not so much a git replacement, as a whole new porcelain on top of the same plumbing.
JJ uses the git binary and maintains a git repository. In co-located mode, the jj working copy is a git working copy. If you use regular git tooling it might be a bit uncertain why you're in detached head mode, but all read-only tooling will work without any problems and if you write to the repo jj will do its best to absorb your manual changes cleanly.
To be clear, Jujutsu is not "porcelain" in the (somewhat archaic) Git sense of "high level tools built on low level tools". We do not share any code with the git project. Jujutsu uses Git as a storage layer, i.e. the direct on disk representation. The algorithms and user interface are all completely written from scratch, on top of this.
You could also write e.g. a Mercurial backend to Jujutsu and it would operate similarly, but using revlog storage vs Git's content addressed store.
> JJ uses the git binary
That's a relatively recent phenomenon. The git binary is used only to fetch and push objects. Previously we used libgit2. Why do this? Because replicating all of git and OpenSSH's feature support for every little random auth flow/crypto algorithm/hardware token/whatever is a battle that can't be won. It's ultimately smarter to just have an uglier interface between the two parts (invoking a command line vs using an API) to make the end-user experience significantly better.
When working with Git objects, jj uses the Gitoxide rust library to natively manage the Git store and upstream Git is not used at all.
Ah, I'd misunderstood how much the git binary was used for. I think I might go with could be a porcelain, if you don't mind? It's far too late for me to edit my comment now.
I'm a smidge late to the "early adopters" party, but I've been using Jujitsu intensively for a couple of weeks now and do not intend to stop :).
A small note here: even though the public version of jj only supports the Git backend right now (I believe there's also support for whatever Google's using internally?), it's designed to be backend-agnostic. So potentially, in the future it could grow its own native backend that could solve some of Git's pain points -- support for huge repositories, native large file storage, etc.
all DVCSs are ultimately the same thing, they are all just providing a human interface to the same data structure. i am not saying this dismissively - human interfacing is an extremely difficult problem where a lot of breakthroughs can be made (and some of these breakthroughs will involve interesting algorithms, see pijul).
so to answer your question, jj allows you to do the same set of things you can do with git, but with (arguably) much better UI/UX.