Block re-override behavior in multi-level inheritance

[SeanTAllen]

Template inheritance (#50) resolves block overrides by inlining the override content directly, stripping the _Block wrapper. This means once a block is overridden at one level, the "slot" disappears from the AST and deeper descendants can't re-override it.

Given a three-level chain:

grandparent:  {{ block content }}default{{ end }}
parent:       {{ extends "grandparent" }}{{ block content }}parent stuff{{ end }}
child:        {{ extends "parent" }}{{ block content }}child stuff{{ end }}

The child's override of content has no effect because the parent already consumed that block — there's no _Block("content") node left in the resolved parent AST for the child to target.

A parent that wants to allow re-override would need to explicitly re-expose the slot:

parent: {{ extends "grandparent" }}{{ block content }}{{ block content }}parent stuff{{ end }}{{ end }}

This wraps the parent's override in a new block of the same name, preserving the slot for the child. It works today but it's not obvious that you'd need to do this.

Jinja2/Django comparison

Jinja2 and Django automatically wrap each override in a new block of the same name, so every level can re-override. They also provide {{ super() }} to include the parent's content within an override. Our current design omits both of these.

Questions for future consideration

1. Should overrides automatically preserve the slot? This would mean wrapping override content in a _Block of the same name during _apply_overrides, so every level can re-override without the explicit double-wrap trick. The downside is slightly more complex resolution logic and potentially surprising behavior if someone doesn't expect the slot to persist.

2. Should we add {{ super() }}? This would let a child include the parent's block content within its override, which is the most common use of re-overridable blocks in Jinja2/Django. Adding super() without automatic slot preservation would be less useful since the slot disappears after one override.

3. Is the current behavior sufficient? The explicit double-wrap works today. Multi-level inheritance where the same block is overridden at every level may not be a common pattern for this library's use cases.

No action needed now. This is documenting the design space for when (if) users ask for deeper inheritance behavior.