If you're talking about "environment variables" in the sense of "shell environment variables", which are provided to perl scripts via the "%ENV" global hash, then I'm curious why the order in which variables are defined should make any difference. As I understand it, environment variables are treated (by Perl and shells) as an unordered set of "name,value" pairs -- that's why ENV is a hash in Perl.

To the extent that certain variables define "search paths", the ordering of elements within the value of such a variable is of course very important. So I could imagine a process, for example, that will come up with two or more distinct elements to be appended to the value of a variable named "PATH", and the order in which these elements are appended can make the difference between success and failure.

But why would it be important (for example) to make sure that you assign a value to "PATH" before (or after) you assign a value to some other variable? Just curious...

(update: reworded last paragraph)

Another update: On second thought, I realize that people often design and implement shell environments by using dependencies among variables -- e.g. "FOO=baz; BAR=$FOO.bar" and so on. But I'm having trouble imagining any other situations where ordering of variable definitions is an issue, and in this case, assigning numeric priorities to the assignments would not seem like the best approach. It would be better for the organization of the hash to represent the dependencies directly.