i would assume the reason this doesn't work is described in Apache's mod_setenv documentation for the SetEnvIf directive:

The rest of the arguments give the names of variables to set, and optionally values to which they should be set. These take the form of
...
3. varname=value

... the third (form) will set the variable to the literal value given by value.

(my emphasis)
source: https://httpd.apache.org/docs/current/mod/mod_setenvif.html#setenvif

even if SetEnvIf would take an environment variable as a value, it wouldn't work as described by lucy24 in this current thread about If / Else with multiple conditions [webmasterworld.com]:

mod_setenvif (which executes before mod_rewrite)

Blerg.

I figured out a sort of hack, but it's not great:

SetEnvIf Request_URI "\.php$" foo=bar
SetEnvIfExpr "%{ENV:foo} =~ /(.+)/" cool=$1

even if SetEnvIf would take an environment variable as a value

Now, see, that's why we needed phranque ;) In all the times I've read that section of the docs, it never sank in that you can only use environmental variables that were set in mod_setenvif. Assuming for the sake of discussion that Apache is being truthful on this point. My first concern was that it only considers environmental variables for the “attribute” section after looking at every possible aspect of the request and all possible header fields, which seems like it would make the server tired. (It would me.)

a sort of hack

That looks cleaner to me, simply because it's all happening in the same module.

Is there a reason to be concerned with running a ton of expressions? I wouldn't do that in Perl or PHP, but I don't know if it will have an impact with Apache.

But if I exclusively use SetEnvIf to set environment variables then it eliminates the whole problem with their order of operations.

SetEnvIf Request_URI "\.php$" foo=bar
SetEnvIfExpr "%{ENV:foo} =~ /(.+)/" cool=$1

Aside: This is subtly different to what you appeared to be trying to do in the first post. In the first post you were trying to assign the value of "foo" to "this" unconditionally. Whereas in the above, you are assigning the value of "foo" to "cool" only when "foo" is not empty.

You don't necessarily need the "expression" (ie. SetEnvIfExpr directive) here, a standard SetEnvIf would do the same thing. For example:

SetEnvIf foo "(.+)" cool=$1

Although if SetEnvIf is first going to look for a "foo" HTTP request header then that may pose a security issue?!

Is there a reason to be concerned with running a ton of expressions?

there would be less concern if these directives were in a config file vs .htaccess because the config file directives are interpreted once upon server (re)start whereas .htaccess directives are interpreted each time a request or subrequest includes the path containing the .htaccess file.