Thanks, this is something to consider at least. However, it doesn't convince me still. While I understand your problem, this problem doesn't really occur in my workflow, so a tool that encourages this workflow doesn't seem appealing and I cannot answer myself yet, why would I need to introduce this problem.
This is because I pretty much never use "edit". Well, not "never", but I avoid it, and it is perfectly avoidable in the vast majority of cases. Also, I don't like to deal with conflicts, as they are error prone, so I try to avoid them as well. Every time I want to change something in an old commit (on the same branch) I'll just add a new commit with barely comprehensible commit message, and I commit every little change. Also, if there is an atomic change in 2 files (function renamed), I usually commit them separately, including file name in the message. Then, after finishing some significant part of work, I'll rebase -i master, reorder commits and most of these "new" fixes will end up with "f" modifier after an olde commit, some I'll just drop. I'll do it in multiple iterations, to see which (reordering) operation results in a conflict, to keep conflict resolution operation as small and straight-forward as possible. So being modal is a good thing, as I'll run rebase a half-dozen times, before changes made up to the moment are all cleared up and I can move forward with committing new stuff. I never want to stay inside of one "rebase" operation for long, if I do, I'll probably --abort, and stop to reconsider what I'm doing here.
Even if "editing" past commit would be completely effortless, I just don't want to do that, because I don't want to think about how "later" changes might affect this place. When I do that, there is a whole new class of potential human mistakes one could make, that just doesn't exist when you always work on the "latest" version of the code. In worst case scenario, I might break some intermediate commit when carelessly reordering stuff, but the final code result must remain the same as before I did rebase. If this isn't the case, there is this uncomfortable scenario that I make some edit which is logically incompatible with a "later" conflict, which I won't notice if it doesn't cause a conflict: and it totally might not cause a conflict. I don't want to worry about that.
It is certainly possible that this particular improvement isn't hugely relevant to you. However this is well beyond "it's nicer" -- it has been a game-changer for me, and the core ideas Jujutsu is built out of result in many such improvements across all kinds of workflows. And I want to emphasize again that this is not contrived; it is how I actually did some work recently.
But also, tools shape our behaviors. Your current workflows are influenced by how Git works, and it's quite possible with Jujutsu you'll change your workflows. Maybe in a direction that you'll like more in the end.
This is because I pretty much never use "edit". Well, not "never", but I avoid it, and it is perfectly avoidable in the vast majority of cases. Also, I don't like to deal with conflicts, as they are error prone, so I try to avoid them as well. Every time I want to change something in an old commit (on the same branch) I'll just add a new commit with barely comprehensible commit message, and I commit every little change. Also, if there is an atomic change in 2 files (function renamed), I usually commit them separately, including file name in the message. Then, after finishing some significant part of work, I'll rebase -i master, reorder commits and most of these "new" fixes will end up with "f" modifier after an olde commit, some I'll just drop. I'll do it in multiple iterations, to see which (reordering) operation results in a conflict, to keep conflict resolution operation as small and straight-forward as possible. So being modal is a good thing, as I'll run rebase a half-dozen times, before changes made up to the moment are all cleared up and I can move forward with committing new stuff. I never want to stay inside of one "rebase" operation for long, if I do, I'll probably --abort, and stop to reconsider what I'm doing here.
Even if "editing" past commit would be completely effortless, I just don't want to do that, because I don't want to think about how "later" changes might affect this place. When I do that, there is a whole new class of potential human mistakes one could make, that just doesn't exist when you always work on the "latest" version of the code. In worst case scenario, I might break some intermediate commit when carelessly reordering stuff, but the final code result must remain the same as before I did rebase. If this isn't the case, there is this uncomfortable scenario that I make some edit which is logically incompatible with a "later" conflict, which I won't notice if it doesn't cause a conflict: and it totally might not cause a conflict. I don't want to worry about that.