This mostly races with #57724 (closed as out-of-date, may be revised, but as mentioned is a breaking change). It's not clear to me why this differentiates behavior between signal vs non-signal types, that seems undesirable.

Thanks. I agree that the signal/non-signal distinction is undesirable.

There is no principled type-system reason those should behave differently in the type constructor. The distinction was only a scoped workaround: the split came from narrowing the initial implementation after omitting all unbound inputs via Partial regressed NgIf generic narrowing. That fixed #69373 without immediately pulling in the broader omitted-input breakage surface, but it special-cases input kind rather than fixing inference uniformly, so I agree it shouldn't land as a long-term design.

I tested two unified alternatives locally before replying:

• Using never fillers keeps the NgIf case green, but breaks the defaulted-generic NoInfer cases: the omitted discriminant contributes never, so T becomes never instead of falling back to its declared default ('single').
• Adapting the latest bound-input-aware shape from fix(compiler-cli): infer correct generic types for directives when so… #57724 makes both the NoInfer and NgIf cases pass. However, the broader typecheck suite then shows the expected inference behavior changes for mixed signal/plain inputs (the failures are mostly those semantic expectations repeated across file-system variants, plus generated-code expectations), consistent with fix(compiler-cli): infer correct generic types for directives when so… #57724's breaking-change concern.

So I don't think the signal-only version should land as-is. Would you prefer that I rework this as part of the broader #57724 approach (potentially behind a flag), or close this PR in favor of revising #57724?