I’ll use this as another opportunity to do me lambda speech.
Any time you see [ | ] you are seeing a lambda. So createTimer, forEach, filter, and all the rest of the times you see the square brackets you are defining a lambda.
There are two places you can define a lambda, inside a Rule and outside of a Rule.
When you define a lambda inside a Rule, the lambda will get a copy of the whole context of that Rule. So triggeringItem, receivedCommand, all your globals, and anything else that has been defined up to the point where you created the lambda will also exist inside the lambda. This is why we can do something like:
timer = createTimer(now.plusSeconds(1), [ | timer = null ])
The lambda created and passed to createTimer has access to the variable timer because timer existed as a variable before the lambda was created.
When you define a lambda as a global, which is what you are really asking about, there is no context to inherit. Consequently a globally defined lambda stands in isolation. So if the lambda needs access to a variable, even if it is a global, you must pass it to the lambda as an argument. Note that lambdas only support up to six arguments.
One thing to realize is that a lambda is an Object. When you create a global lambda you are creating a single lambda Object that all the Rules that call that lambda share. And calling the lambda is not thread safe. So it is possible for two Rules to call a lambda at nearly the same time and end up stomping on each other. Be very careful with lambdas.
Based on my experience, personal and helping people on this forum, I strongly recommend against the use of lambdas except under the most dire circumstances. It will almost always be worth it to refactor or change your approach to avoid the need for lambdas. Consequently I treat them as a code smell. You would have to pass a very high bar to convince me that they are absolutely required in your situation.
And even if you convince me that the lambda is needed, I’m likely to recommend farming out the task to a separate Rule (Design Pattern: Separation of Behaviors) or to an external script or service.
About the only time I’m OK with the use of global variables any more is like the use in OAuth2 using just OH Rules and myopenhab.org where the lambas encapsulate code that must be called from multiple different Rules BUT are almost guaranteed that the lambda will never be called twice at the same time.