Bug: Accordion does not work with Angular new control flow (@for)

[matigaleanodev]

Description

When using Angular new control flow syntax (@for), nb-accordion does not behave correctly.
Accordion items rendered with @for are not properly initialized or updated, while the same template works as expected when using *ngFor.

This seems to be related to how nb-accordion initializes and tracks its projected nb-accordion-item children.

---

Environment

• Angular: 21.x
• Nebular: 17.x
• Browser: All

---

Expected behavior

nb-accordion should work correctly regardless of whether accordion items are rendered using:

• *ngFor (legacy syntax)
• @for (new Angular control flow)

Accordion items should: - Render correctly - Expand and collapse properly - React to user interaction

---

Actual behavior

When nb-accordion-item components are rendered using @for:

• Only the first accordion item is initialized and registered by the accordion
• The first item works correctly (header interaction and expand/collapse behave as expected)
• Subsequent items rendered by @for are ignored, as if they did not exist
• The accordion behaves as if it contained a single item, even though multiple items are rendered in the template

Using *ngFor instead of @for correctly initializes and registers all accordion items, and the accordion behaves as expected.

---

Minimal reproduction example

<nb-accordion multi>
  @for (item of items; track $index) {
    <nb-accordion-item expanded>
      <nb-accordion-item-header>
        {{ item.title }}
      </nb-accordion-item-header>
      <nb-accordion-item-body>
        {{ item.content }}
      </nb-accordion-item-body>
    </nb-accordion-item>
  }
</nb-accordion>

The same template works correctly when using *ngFor.

---

Additional notes

This issue affects compatibility with Angular's recommended modern template syntax and makes it difficult to adopt @for in applications using Nebular.

Since *ngFor is treated as legacy and Angular actively enforces and promotes the new control flow syntax through warnings and template migrations, this issue becomes a blocker for adopting current and future Angular best practices.