Why can't this use the prevalent scheme of clearing `STCmaybescope`? Maybe I'm looking at the commits in the wrong order, the PR is a bit messed up.

Just a single layer, why not `a.b.c`?

Also seems to work for nested scopes. Could we have some weird semantic order of nested functions or so that conflicts with this sequence number scheme?

order the variables are declared??? Thought you were the native speaker :). Did you mean order the declaration of variables?

Shouldn't this unset STCreturn if that doesn't apply?

Should be OR'd in is a bit colloquial. I think what you're trying to do here is to infer whether parameters cannot escape, then add STCscope, but also STCreturn if they can be returned.

Well get to that before merging the feature branch, of course none of that stuff should become an error, without proper deprecation.

Those escape checkers look a bit redundant, but the subtle semantic differences and better error messages are probably worth it.

But they already are delegates, looks like a potential feedback loop. Please clarify in which order delegates are treated.

What a pity we still don't use such tools as `v.nestedrefs.canFind(fd)`. Also nestedrefs is a misleading name for an array holding functions, anyhow.

Please get accustomed to early return/continue to avoid such deep nesting ;). ``` d ìf (fdp is nulll) continue; ```

Sure about this? Couldn't one of the DotVarExps return a value with an independent lifetime?

Looks like it's not strictly part of the commit Issue to fix 15544.

That's a very undescriptive name, as usual any translation a reader has to juggle in mind while going through the code makes understanding harder, a bit similar to using rare loanwords in articles. How about `Escapes` instead? I wouldn't argue if that name didn't hinder my understanding of the code.

Test case for that would have been nice.

Interesting, how does this work @WalterBright? Does the field get tainted by the assignment of a scoped value?