IMO this solution is error prone and requires a lot of responsibility from library developers as we will need to check existence of every prop that we are trying to apply. We will also need to test these cases to ensure that it works. For example, this PR already adds 3 additional tests.

Taking into account that it affects all components that use trigger pattern (Popup, Menu) I still think that it's better to update applyTriggerPropsToElement() to handle it inside .cloneElement():

React.cloneElement(children, {
  ...nonMergeableProps, // aria, id, etc.
  ...children.props,
  ...mergeableProps // callbacks & ref
});

We also cannot rely on reading props in examples like this as we don't really traverse React tree (which is much more complex). In that example MenuTrigger will not be able to read props of Button.

And even if it works properly in the snippet below it's a side-effect.

const CallButton = React.forwardRef((props, ref) => {
  return (
    <Tooltip content="bar" relationship="label">
      <Button
        {...props}
        ref={ref}
        // works as Tooltip reads props
        aria-label="foo"
        // works as we override `props` passed by "Menu"
        aria-haspopup="false"
      >
        Toggle menu
      </Button>
    </Tooltip>
  );
});

Discussed in a meeting. In summary, the issues @layershifter described are nuances of prop merging in general. These trigger props are just one instance of prop merging in our library, but we do it in many places, in every component (for native props on component's root, as well as any slot).

It's probably worthwhile creating a prop merging helper that can make sure it's done safely in all cases. However, it seems out of scope to me to include that in applyTriggerPropsToChildren, which is just a wrapper around React.cloneElement.