> The existing hooks: post open, post close, post clone (patch submitted),
> are insufficient in the tab clone case where users employ custom tab
> parameters. Such tab parameters often need post-clone curation. In my case,
> cumbersome tab-bar advice is needed to work around cloning. Others might
> experience the same need.
>
> I see a few ways we can help address this. Once we agree on an approach,
> I'm happy to submit a patch.
>
> 1. Alter tab-bar-tab-post-open-functions to accept an optional second
> argument, namely, the originating tab, iff tab-bar-new-tab-choice 'clone.

Adding a new argument will break the existing uses.  This could be
avoided by using (condition-case ... (wrong-number-of-arguments ...)).

But much simpler would be just to check the dynamically bound value
in the hook, e.g.:

(add-hook 'tab-bar-tab-post-open-functions
          (lambda (tab)
            (when (eq tab-bar-new-tab-choice 'clone)
              (message "Cloned tab %S" tab))))

> 2. Create a new hook tab-bar-post-duplicate-tab-functions, the functions of
> which accept two arguments: the originating tab, the cloned tab, and where
> the hook runs iff tab-bar-new-tab-choice 'clone.

The existing hook tab-bar-tab-post-open-functions doesn't accept the
originating tab.  But still it's possible to get the originating tab
using tab-bar--tab-index-recent.

> 3. In harmony with clone-frame, tab-bar could propagate tab parameters to a
> cloned tab (it already saves them naturally, for use in undo close tab),
> modulo internal tab-bar parameters. A post-clone hook would still be needed
> to allow a user to control their custom parameters. (A new post undo-close
> tab hook patch is pending to support the undo case.)

A cloned tab already inherits the group with tab-bar-new-tab-group.

And it's easy to get other parameters from the originating tab using
tab-bar--tab-index-recent in the tab-bar-tab-post-open-functions hook.