👍🏻

Why the order change?

Because then if you select both TestSign and Sign, you'll get TestSign. Previously, you'd get both (I also changed if to elseif), which ought to have caused an error (multiple defined variables), but probably just caused confusion.

Can't say I'm familiar with this syntax. That's setting $(AZURE_CLIENT_ID) to what was in ${env:servicePrincipalId}? Couldn't we use ${env:servicePrincipalId} directly below?

This entire task logs in using the service connection (temporary token obtained via OIDC), runs the inline script, and then clears the environment (this last bit is the main answer to your question). We need to smuggle out the connection info and use it to obtain a new temporary token (the az login below) that lasts for the subsequent steps. It's apparently just an annoying design.

The alternative is to turn every PowerShell step below that does signing into an AzureCLI task and add lines to rename the environment variables into the AZURE_... ones expected by the sign command. It turns out, that really isn't any better than this approach, though both kinda suck.

The best solution would be a dedicated task for signing that knows how to use the service connection directly, but as far as I can tell that task doesn't exist without adding extensions to Azure DevOps (you can't just pull them directly from public repos like in GitHub Actions), and it wasn't clear that we could do the filtering needed either. So I preferred this approach.