There's no parsing problem with delayed expansion (e.g. "!VAR!" instead of %VAR%) and for loop variables (e.g. "%%a"). The solution is thus to execute in a local scope that enables delayed expansion and command extensions [1]. 

That's easy enough, but then there's the problem of how to evaluate the `set` commands in the global scope, without the help of delayed expansion to prevent parsing errors. I did some research, and apparently the common trick is to end the local scope inside of a `for /f` loop. Then subsequent `set "%%a"` statements in iterations of the loop execute in the global scope. 

The final problem is building the command to execute in the local scope, for which the `for /f` loop iterates the output lines. `set var` returns a line with "var=value", which can be passed back into `set "%%a"`. So I decided to build up a sequence of `&` concatenated `set var` and `echo var=` (clear) statements in an EXPORTS variable.

I added default values for PROMPT ($P$G) and PATH (%SystemRoot%;%SystemRoot%\System32), for when they're not defined. I made sure that deactivate.bat does not leave these defaults in place. The original values, whether defined or not, should be restored exactly as they were.

All of this adds to the length of the scripts. They're roughly doubled in size. But there should be no more problems with an odd number of quotes and/or special characters in any of the variables that get set.

---
[1] The activate.bat and deactivate.bat scripts have been naively relying 
    on the default enabled state of command extensions, e.g. `for /f`
    loops and `if defined` statements.