I'm about the same. jj is kind of perfect for that. Example:

# I've finished something significant! Carve it out from the working "change" as its own commit.

    `jj commit --interactive` # aka `jj commit -i` or `jj split`, depending on how you prefer to think of it: making a commit for some work, or splitting a separate commit out of the working change.

# Oops, missed a piece.

    `jj squash --interactive` # aka `jj squash -i`

# Let me look at what's left.

    `jj diff`

# Oh right, I had started working on something else. I could just leave it in the working change, but let me separate it out into its own commit even though it's unfinished, since I can always add pieces to it later.

    `jj commit -i`

# Wait, no, I kind of want it to come before that thing I finished up. Shoot, I messed up.

    `jj undo`

# Let me try that again, this time putting it underneath.

    `jj split -B @-` # aka `jj split --insert-before @-`. @ is the working change, @- is its immediate parent(s), @-- is all grandparents, etc.

# Note that instead of undoing and re-selecting the parts, you could also `jj rebase -r @- -B @--` to reorder. And in practice, you'll often be doing `jj log` to see what things are and using their change ids instead of things like `@--`.

# I also have some logging code I don't need anymore. Let me discard it.

    `jj diffedit`

# Do some more work. I have some additions to that part I thought was done.

    `jj squash -i`

# And some additions to that other part.

    `jj squash -i --into @--`

# etc.

There's a lot more that you could do, but once you internalize the ideas that (1) everything is a commit, and (2) commits (and changes) can have multiple parents thus form a DAG, then almost everything else you want to do becomes an obvious application of a small handful of core commands.

Note: to figure out how to use the built-in diff viewer, you'll need to hover over the menu with the mouse, but you really just need f for fold/unfold and j/k for movement, then space for toggle.

> I often find that in the process of making one change, I have also made several other changes, and only recognize that they are distinct after following the ideas to their natural conclusion.

I do that all the time. With git, everything starts "unstaged", so I'd use magit to selectively stage some parts and turn those into a sequence of commits, one on top of another.

With jj I'd do it "backwards": everything starts off committed (with no commit message), so I'd open the diff (`D` in majutsu), selecting some parts and "split" (`S` in majutsu) to put those into a new commit underneath the remaining changes. Once the different changes are split into separate commits, I'd give each a relevant commit message.