I have two ideas:

1. Provide tuiGlobalRipple directive that will applied for tui-root, listen mutations, and apply ripple for given selector. Example:

<tui-root tuiGlobalRipple="button,a,.ripple" > ...

This solution allow to apply ripple for any elements (including custom projects elements). But we should develop this directive carefully, for avoid performance regression with large DOM trees.

2. Provide config that contain booleans for enable / disable ripple for certain TUI elements. Example:

@NgModule({
  ...
  providers: [
    ...
    tuiUseRipple({
      button: true,
      link: false,
      default: false,
    }),
  ],
})
export class AppModule {
}

I think this solution more reliable, because of we do not need to listen DOM mutations and care about performance issues. But it require apply directive for each component we want to add ripple.
Also I think, we should provide a way for customize configs, to add some custom components:

type TuiRippleKey = 'button' | 'link' /* ... */;

export interface TuiRippleConfig {
    default: boolean;
    
    [K: TuiRippleKey | string]: boolean
}

export declare function tuiApplyRipple(key: TuiRippleKey | string, element: ElementRef<HTMLElement> /* ... */): void;

// Example typing

const config: TuiRippleConfig = {
    default: true,
    button: false,
    link: true,
    test: false,
};

Developers can apply ripple to theirs components:

export class TestComponent {
  constructor(
    elementRef: ElementRef<HTMLElement>,
    /* ... */
  ) {
    tuiApplyRipple('test', elementRef);
  }
}

We already have a directive that does the ripple effect. It relies on touchstart, touchend and touchmove events and I believe it should be quite performant, it uses RxJS but it could use some refactoring. We should rework it to PointerEvents so that it is not just touch, some people might want it for clicks too.

It listens to events on the ElementRef. Your idea with a new directive on tui-root is good. We can just call it tuiRipple and put into experimental package, deprecating the current one. Just need to think of a way to customize the color. As for global DI config, it would require a service of some kind which would need to be injected somewhere to start working. I guess directive is cleaner.

I believe we should allow passing the CSS selector rather than a config. It would just listen to all bubbled events inside our directive and when we believe it is time to initiate ripple we can just check for target.closest(OUR_CSS_SELECTORS) to find where we need to initiate it and skip it if it is null. That should not be a problem performance-wise as it will only traverse DOM with a fast native method once per pointerdown event.