There are multiple use-cases where one would like to reason about content provided to a component (check if content was provided at all, count the number of items etc.).

To make the discussion more concrete let's consider the following markup (full runnable scenario):

<my-container>
      <my-item></my-item>
      <my-item></my-item> 
      <my-item></my-item>
</my-container>

Given this markup the <my-container> component might want to answer the following questions:

• was content provided at all (existing, popular issue.: No ability to check if <ng-content> was provided to the component #26083)
• how many items were provided (as of today this could be done through content queries only).

On top of this the <my-container> implementation might want to do the following (all the provided examples boil down to the ability of projecting items individually):

• wrap each item into some markup;
• project only 2 first items;
• project every second item (or items in 2 separate columns);
• etc. etc.

Achieving any of the use-cases listed above is very difficult in the current Angular and it steams from the fact that one can't reason (count, pick-up, check presence etc.) about individual items to project.

While content queries can be used, to some degree, to reason about content items individually, the content queries approach has its problems as well:

• we end up with 2 mechanism operating on content (content queries and content projection) - those 2 mechanism have different APIs, different capabilities, need to be learnt separately etc.;
• there is a fundamental mismatch between 2 mechanism: content projection operates on "blocks" that can't be reason about (but capture content), while content queries are good with individual items but don't capture content (we can't insert result of a content query into the DOM).

This fundamental mismatch between content projection and content queries leads to many surprising situations and use-cases that can't be implemented really. Again, here is a "typical" example: https://stackblitz.com/edit/angular-ivy-sumkgl?file=src%2Fapp%2Fapp.component.ts

In short: content projection and content queries are good mechanisms while used separately, but as soon as we try to use both mechanisms together we start to bump into serious problems.

The idea behind opening this issue is to capture use-cases that are difficult to implement and expose problems where both content queries and content projection are used together. This should open ways to designing a more powerful content projection where it is possible to reason about and project content with one API. To set expectations: there are no immediate implementation plans, we want to capture use-cases and experiment with different APIs first.