Let me first of all be clear that I believe you have good reasons, and reiterate that I think it's great and want the features, I'm just trying to understand why it doesn't/can't work with my current rebasing workflow.

Take my example before, X-->Y-->Z(HEAD) where each of X,Y,Z here are (at least potentially) multi-commit branches, not just commits; based on top of each other.

If I need to fix something in the 'merged' (I said 'amalgamated' previously exactly to avoid that, but we can stick with scarequotes if you like ;)) result, and it belongs say with Y, then I will either:

    git fixup <some-commit-between-X-and-Y>

    # fixup = my alias for:
    "!f(){ target=\"$(test -n \"$1\" && git rev-parse \"$1\" || git fzsha rev-parse)\"; git commit --fixup=\"$target\" ${@:2} && EDITOR=true git rebase -i --autostash --autosquash \"$target^\"; }; f"
    
    # basically commit -m'!fixup <target-commit>', and then rebase target-commit^ to apply it

or if it belongs as a standalone commit on that branch:

    git commit -m 'whatever'
    git rebase -i Y # and move it to the top so the Z stuff follows it

and then in either case:

    git branch -f Y <new-location>
    
    # if I'm doing this repeatedly, <new-location> is often HEAD~N, for however many N commits on Z.

For this feature at least, it seems like GB could be implemented as automation/abstraction of that workflow, which (clearly) is perfectly penetrable to git.

I've been working like this for more than a decade, so even if GB's better & easier it's a tough sell to partially break interoperability; to need to use GB GUI to manage the situation rather than have it as a choice.