Ben Knoble [off-list ref] writes:

quoted

Thanks for the work on this topic!

Ditto! I suspect that using a combination of « git history squash
» and « git replay » to emulate « git rebase » in non-interactive
autosquash mode will be much faster, too, due to the differences
in implementation. If that proves to be the case and we can safely
do so with feature compatibility, I wonder if it will be worth
making the non-interactive autosquash rebase actually delegate
through a history squash + replay.

Yes, that would be an ideal future, and these efforts move us in
that direction.

I’m sure there’s a few instances that couldn’t be done (for
example when the special! commits cross the current range and
upstream; that is, a fixup! for an upstream commit or some such
oddity;; there are also conflicts to consider), but in the cases
it can be it ought to be a performance win.

Since you assume "we can safely do so with feature compatibility"
above, once we are finished, there will, by definition, be no
such "special" commits that the combination cannot handle.  By
the time that happens, we will have replaced the internals of
"rebase [-i]" with a new implementation that does not need to
touch the working tree.

That would indeed be an exciting future.