@luyuwuli Actually, I made a mistake - I meant not using $ in the fashion varname$123. I will correct the text.

@Wjx Thanks. Glad you found it useful.

@luyuwuli Thanks for spotting this, I had a value of a in my session and overlooked that. Corrected.

@luyuwuli This sounds correct, but "StrictLexicalScoping" does more than that, and not only for With. I don't really know the details of how it works, the right person to ask is Daniel. However, in some sense, the whole point here is that we don't really want to know these details.

@luyuwuli Sure. Waiting for other answers is always the right thing to do.

The f[999] example reduces to Unevaluated[Function[a,999][a]]/.a->0 returning Function[0, 999][0]. Replacement occurs before Function evaluates. This is normal and not related to renaming.

The best way to avoid renaming problems is to avoid names altogether, which is entirely possible.

@PierreALBARÈDE "Replacement occurs before Function evaluates. This is normal and not related to renaming." - there is nothing normal about it from the language design standpoint, because it breaks lexical scoping for Function with named args, and makes it unsafe to pass it as an argument to other functions. But it appears that you didn't read my post carefully. I did not say that this was related to renaming. I said that this was one of the instances where renaming could've fixed the problem, but was not used by the system, causing this bug.

This f[999] example is certainly not minimal. Please examine it with Trace, strip it down, and you may see that it is all normal in the end.

@PierreALBARÈDE You seem to be missing the point of this example in my post. It was not supposed to be "minimal" in the sense you mean. It was supposed to be a realistic (if short) example of use, which leads to confusion (fully justified) for uninitiated, and which illustrates the behavior that many, including myself, consider a serious language bug (which might be unfixable, but bug nonetheless). Specifically, the a parameter inside Module should've been renamed during g[fn] function call, had renaming mechanism worked in that case - and this would've been one way to fix this.

Honestly, I don't see what more is here to discuss, and don't have much time for it either. My comments seem quite clear, to me at least.

You can't expect ReplaceAll do perform renaming, that is not its job. I am working on renaming bugs, there are unfortunately some, but this one is not. So it may be a bad example for an otherwise good crticism.

It is not about ReplaceAll. It is about RuleDelayed, and other constructs which do the renamings

It is about scoping. ReplaceAll is about replacements

By the time you get Unevaluated[Function[a,999][a]]/.a->0 returning Function[0, 999][0], it is already too late

Yes that is exactly what I mean.

Then what is it you disagree with me about?

In the first place. do you agree that the f@999 example is equivalent finally after removing all unnecessary stuff to Unevaluated[Function[a,999][a]]/.a->0 ?

Depends on what you mean by equivalent. It is that equivalence that breaks things, so I'd rather say these two things should not be equivalent - but they are in the current semantics of WL

In other words, by the time you get to Unevaluated[Function[a,999][a]]/.a->0 or similar, the buggy behavior has already happened

Well I could send you a small notebook or maybe open a new public question, what do you prefer?

I really have no time for either right now, sorry :) But you sure can ask a new question, there are many others who might have the time to answer.

Yes I will do it. Thank you for your many contributions (including answers to my questions) by the way.

@PierreALBARÈDE Sure, np )