I found some additional info on the $ENV_VAR vs ${{ env.ENV_VAR }} syntax here: https://docs.github.com/en/actions/writing-workflows/choosing-what-your-workflow-does/store-information-in-variables#using-contexts-to-access-environment-variable-values

You can access env variable values using runner environment variables or using contexts.

So the $ENV_VAR is a "runner environment variable" and are expected to work in run steps and are processed by the shell you are using on the runner (i.e., bash in our case).

The ${{ env.ENV_VAR }} is using the "env context", which sounds like the generally more "works everywhere" way of doing it:

The instructions in the other parts of a workflow are processed by GitHub Actions and are not sent to the runner. You can use either runner environment variables or contexts in run steps, but in the parts of a workflow that are not sent to the runner you must use contexts to access variable values.

...so I'm not entirely sure how this worked before, other than previously the slack-post-message-action code was using double strings and the bash shell, so perhaps that's why the "runner environment variable" syntax was working?

I ended up changing slack-post-message-action to use bash ansi C quoting so that callers could include things like single quotes, but presumably that also meant the $ENV_VAR syntax stopped being interpolated.