[Idea] Extend template inheritance beyond 3 levels

[ChrisBlankDe]

Summary

Improve AL-Go template inheritance so settings are reliably propagated through deeper template chains (4+ levels), not only up to three levels.

Current limitation

Inheritance currently works well for 3 levels:

AL-Go PTE Template -> Customer PTE Template -> Customer PTE

When adding a 4th level, inheritance appears to break for settings defined in intermediate templates:

AL-Go PTE Template -> Partner PTE Template -> Customer PTE Template -> Customer PTE

Specifically, settings defined at level 3 in .github/AL-Go-TemplateRepoSettings.doNotEdit.json are not inherited into level 4. It looks like only values from .github/AL-Go-Settings.json are written to .github/templateRepoSettings.doNotEdit.json in the target repository, which drops previously inherited template-level values.

This likely affects Project Settings in the same way.

Proposed improvement

Update the inheritance mechanism to support at least 4 levels, ideally an unlimited depth, by recursively merging inherited template settings across the full template chain.

Suggested behavior

1. Inheritance should include all applicable settings from every parent template in the chain.
2. Merge behavior should be consistent regardless of inheritance depth.
3. Effective settings should remain deterministic and transparent (for example, with clear precedence rules and optional diagnostics showing setting origin).

Example scenario

• Repo A (Partner PTE Template):
  • Create from AL-Go Template
  • Add a unique setting
  • Configure as template repo
• Repo B (Customer PTE Template):
  • Create from Repo A
  • Add a unique setting
  • Configure as template repo
• Repo C (Customer PTE):
  • Create from Repo B
  • Add a unique setting

After running Update AL-Go on each repo, Repo C should contain inherited settings from both Repo A and Repo B, not just the nearest layer’s direct settings.

Note: AI only helped me phrase this text. The thoughts and ideas behind it are my own.

Contribution (Optional)

• I would be open to contributing to this idea (implementation, documentation, testing, etc.)