Per above.

@jelbourn yes, but I think there may be valid use cases for that, and that it overall doesn't even compare with the behavior of ::ng-deep at the start of a CSS selector.

I think a valid use case is when you want a reusable <hgroup>, where you want your component's users to pass <p> elements and one heading element, in arbitrary quantity and order, and possibly containing markup such as <span>, <em>, <a> and whatnot - which is a reason not to pass those by string component input. In that situation, it's obvious that your component has a good reason to apply style to its child contents. What's more, people passing child content to this component would or at least should expect style to be applied, as it's part of the component's purpose. To reuse your words, the authors of the child content of that particular component would be wrong not to intend that style to be overwritten.

Without saying that it's an Angular superhighway that everyone should use in their project, I think it would be fair not to discourage people to use this tool, in cases (such as this) where its behavior isn't chaotic.

Otherwise, I would ask you : if not using ::ng-deep, how should I implement the component described above in a new Angular app ?

You could either use design tokens like Angular Material does, or consider some css custom properties as part of your public API.

ng-deep is really a last resort solution when you have no other choice. Using ng-deep is akin to reaching to a private API.

I found no source in the Angular documentation about "design tokens". I doubt it's as easy to use as ::ng-deep.

Say I go with the custom CSS properties solution. That means that my component, the <hgroup>, needs to :

1. publicly list all the CSS properties it intends to change on the child content
2. specify the name of each CSS variable it will declare, and how it should be applied to CSS properties (which for which)
3. the user of the component needs to manually apply all those variables to all those properties themself, for all the elements it passes as child content. And there's an additional layer of complexity if you want to use CSS selectors.

That seems to me like a giant bug nest, especially when compared to the simplicity of using ::ng-deep.

Using ng-deep is akin to reaching to a private API.

Yes, because this documentation declares it so, but that circles back to the reason why I want that to change.
What makes it so private ? Why preventing a component that would document itself as applying style to anything under it, from doing so ? Can you give a concrete example ?
More specifically, I don't see why using ::ng-deep in the specific way I described is more invasive than the other ViewEncapsulation modes, especially ViewEncapsulation.None which (as far as I understand it) is the same as the worst use of ::ng-deep. Doesnt ViewEncapsulation.ShadowDom also apply its own style to its child content just the same ?
Yet both of those remain fully documented and supported.