You can definitely fake it. It’s probably not worth it though. Fossil’s workflow might prove lovely without the need to rewrite, but if not just use a tool like git that allows it.

What I like about this question, however, is what it reveals about our assumptions, and what it says about what the words “commit” and “history” mean, and what it is we want out of a version control system.

The truth is that a commit is what I say it is, whether I’m using git or Fossil or anything else. This means that it’s absolutely always guaranteed to be subjective, and has only the meaning I give it. Preventing rewrites might have some workflow benefits, I’m quite open to the idea that there are advantages to the way Fossil does things. But the idea that rewrites should be prevented in principle because history should be preserved is really very funny to me. It’s only possible to preserve the history of the things I said are history in the first place.

You can definitely fake it if determined, it's sqlite under the hood. Your way would work but the branch will live forever (possibly closed) if you push it from the local repo.

Easier is to copy the repo, do a bunch of feature work there, then rsync over to the shared repo and commit. I don't bother though, local history has the mistakes and backtracking enshrined.