Declarative Pipeline environment variable precedence undocumented between top‑level and stage‑level scopes

Goal

Determine the authoritative precedence rule when a Declarative Pipeline defines the same environment variable at both the top‑level environment directive and a stage‑level environment block.

Constraints and uncertainty

The Jenkins documentation describes inheritance but does not explicitly state which scope wins when names collide. Empirical testing across Jenkins 2.361, 2.372, and 2.385 shows stage‑level values take effect inside that stage, yet the absence of a documented guarantee leaves the behavior vulnerable to silent changes. Additionally, variable resolution can differ between shell steps (sh), Groovy steps, and the withEnv step can temporarily mask the underlying precedence.

Questions

1. Is stage‑level override of a top‑level environment variable an intentional, stable contract or an implementation detail?
2. Does the precedence apply identically to sh, bat, and Groovy env.VAR accesses within the same stage?
3. Are there any pipeline constructs (e.g., when conditions, options, or agent directives) that evaluate the variable before the stage‑level override takes effect?