PR Checklist

Please check if your PR fulfills the following requirements:

• The commit message follows our guidelines: https://github.com/angular/angular/blob/main/CONTRIBUTING.md#commit
• Tests for the changes have been added (for bug fixes / features)
• Docs have been added / updated (for bug fixes / features)

PR Type

What kind of change does this PR introduce?

• Bugfix / performance improvement

What is the current behavior?

Currently the styles of any live Angular component with None and Emulated style encapsulation type are bleeding into the live Angular component's instance of ShadowDom ones.

This is bad for two main reasons:

• This violates the standard HTML concept about Shadow Dom style encapsulation, making them fragile and prone to CSS injection. In addition, the current behavior is counter-intuitive for HTML developers, that are expecting real isolation when shadow Dom is involved: https://developer.mozilla.org/en-US/docs/Web/API/Web_components/Using_shadow_DOM#shadow_dom_and_custom_elements
• This silently introduces a performance degradation when many instances of Angular components are composed in an application, mixing "ShadowDom" and other encapsulation types. The degradation is roughly of O(M*N) magnitude, where M and N are the component instance counts of None+Emulated type and ShadowDom type respectively.

Issue Number: #57801
Issue Number: #35039
Issue Number: #5059

What is the new behavior?

The new behavior should reflect exactly the HTML spec about Shadow DOM: any component's private style must be injected as before, but no other component's style must be loaded inside the Shadow DOM.
Contrarily to the documentation, that states that the shared styles are injected to avoid "unexpected styles" when nested Angular component are used inside a Shadow-DOM ones, the developer must/can:

• Use other Shadow-DOM based components with their own private encapsulated styles
• Use <slot> to permit external style to be used when the component is a "container".

However, the behavior cannot be changed without the dev's consensus.

The proposed PR exposes a global DI flag that the application can enabled (so app-wide) to enable the new behavior.

However, a more granular approach should be used. Other possibilities, more user friendly, are:

• A new enum flag of the ViewEncapsulation type (something like IsolatedShadowDom) that explicitly denies shared style injection;
• A new Component annotation property;
• A module-level config DI object.

Does this PR introduce a breaking change?

• Yes
• No