It looks to me like the main difference is that with Git you can't have multiple worktrees on the same branch. Apropos of your comment "Note: this working directory now not a tip of trunk anymore…", to Git being on the tip of a branch is a thing of note, so it doesn't ever want to accidentally invalidate another worktree's notes about being on the tip of a branch.

In Git, that'd be:

    $ cd ~/work/fossils/projx.git

    $ git worktree add ~/work/project_x master # add a worktree with the 'master' branch checked out

    $ cd ~/work/project_x

(Edit, edit, edit)

    $ git commit -m 'descriptive msg'

(Get an idea, but for whatever reason do not want to disturb this directory)

    $ git worktree add ~/work/radical_idea -b cool_idea # add a worktree with a new 'cool_idea' branch

    $ cd ~/work/radical_idea

(Edit, edit, edit)

    $ git commit -m "cool idea"

(Test..)

    $ git switch master # whoops, can't do this
    fatal: 'master' is already checked out at '~/work/project_x'

    $ # let's just do the merge in the other worktree, since we're about to switch anyway

    $ cd ~/work/project_x

    $ git worktree remove ~/work/radical_idea # or: rm -rf ~/work/radical_idea && git worktree prune

    $ git merge cool_idea

(Continue hacking…)

> <note here there is no sense of this being an inferior or “sub” checkout>

There is not in worktrees either. You can use worktrees with a bare repository for instance. It's just that for backwards compatibility and the convenience of most users a non-bare clone creates a default worktree. That's exactly what you see if you `git clone` a repository then `git worktree list`, a worktree corresponding to the working copy.

Seeing this makes me want to try out fossil now.