Leveraging --rebase-merges --update-refs mechanism to rebase several branches in one run

This idea comes from a repo[1] where I am experimenting with code variants: on one side I have a branch where I add to the core mechanisms, and on the other(s) I have several branches where I experiment with different rendering options.

There are indeed 2 different workflows here:
- improving the variants themselves, where occasionally some fixup or new
  commit for the core branch gets introduced
- adding feature to the core branch, then merging that into each variant,
  where fixups already appear quite regularly

That produces a set closely-related branches with lots of merges, and applying the fixups is a bit tricky.

The "core + 1 variant" case pretty much works out of the box, with --rebase-merges and --update-refs generating a perfect instructions sheet.

But if I was to rebase just one variant while rewriting the core branch, obviously all other variants would still fork off the pre-rewrite core branch, and we'd loose all chances of automating the same work on the other variants.

OTOH, if I get `git-rebase` to generate the instruction sheets for those other variants first, strip them (manually) from the common part, and insert them in the instruction sheet of my "core + 1 variant" case ... I do get the whole of my branches rebased together, and sharing the updated core.

So the question is, would there be any obstacles to let git-rebase automate this completely? By chance it could even be a trivial change? I guess we'd only want this feature to be enabled under certain conditions, like --update-refs being specified so the many heads of the rebase would be reachable.

[1] https://github.com/ydirson/test-yew-tutorial/tree/opr is the "core" branch, and branches opr-* are the variants