Does extending `--empty` to git-cherry-pick make sense?

The `--empty=(keep|drop|ask)` option added to git-rebase in e98c4269c86019bfe057a91b4305f784365b6f0b seems like it would be applicable to git-cherry-pick (and maybe git-revert for completeness?). While the shared sequencer code likely would already handle this fairly well (at a cursory glance from someone with very little knowledge of C or git's codebase, admittedly), it's only exposed via git-rebase.

The use case in which this came up involves a semi-automated workflow for moving commits between branches. At a high level, a tool is:

- Identifying commits to be picked based on a specific trailer value
- Using git-cherry-pick with `-x` to pick those commits
- Relying on the presence of the `(cherry picked from commit ...)`
  trailer to avoid re-picking commits that have already been picked

If the picked commits are then rewritten in the upstream such that there are squashes or fixups, that trailer can end up missing in the upstream. The next time the tool runs, it will end up trying to re-pick commits that are already represented there. As a result, those commits become empty upon being picked a second time and the cherry-pick ends up breaking for the user to resolve:

    $ git cherry-pick main
    On branch feature
    You are currently cherry-picking commit cfd7cd9.
      (all conflicts fixed: run "git cherry-pick --continue")
      (use "git cherry-pick --skip" to skip this patch)
      (use "git cherry-pick --abort" to cancel the cherry-pick operation)

    nothing to commit, working tree clean
    The previous cherry-pick is now empty, possibly due to conflict resolution.
    If you wish to commit it anyway, use:

        git commit --allow-empty

    Otherwise, please use 'git cherry-pick --skip'

I'll spare the details, but we do expect this to happen with enough frequency that we'd really like to be able to prevent it. The `--empty=drop` option sounds like exactly what we want here:

    --empty=(drop|keep|ask)
    How to handle commits that are not empty to start and are not
    clean cherry-picks of any upstream commit, but which become
    empty after rebasing (because they contain a subset of already
    upstream changes). With drop (the default), commits that become
    empty are dropped.

Is there any real barrier to exposing that option to git-cherry-pick as well? Was this an oversight, or intentionally left out? The corresponding commit message doesn't seem to indicate any specific reason for limiting it to git-rebase.

Thanks, -Brian Lyles