Could you elaborate what is it solving? What I see is that with strict variables, we silently discard a runtime error, which feels... counter-intuitive? What is the use case and problem that this PR is trying to solve?

Adjustment for #643 regarding templates in StrictVariables mode.

When using 'include', the code checks whether named parameters collide with current local variables.

Problem:
{{ include 'name' x: 'hello' }}
The named parameter 'x' is not defined in the current scope, so the lookup would trigger a ScriptRuntimeException.

I have refactored the variable resolution logic and implemented a non-throwing TryGetValue method in TemplateContext.

Test Changes:

• Parameterized the entire TestIncludes class using [TestFixtureSource]
• It now runs in two modes: with StrictVariables enabled and disabled
• Refactored/fixed several tests

I hope this isn't too excessive 😅

I'm not sure that the previous fix #643 was actually the right thing to do, and looking at this PR, we are building maybe more workaround on something that should be simpler.

Template arguments are transformed to local variables (my_arg => $my_arg) and in the code here we are saving previous local and restoring them, and then we have to deal with restrict variables.

TemplateContext actually has a PushLocal/PopLocal that creates a new local context for local variable. We should probably use that instead, along the PushOutput/PopOutput that we already have for RenderTemplate. That way we won't have to save/restore anything manually, and the code should be simpler/safer.

Probably closing this PR and if you want to open a new PR with my proposal above, it will be welcome, thank you.

Thanks for the review. I'll check it again.