letting program changes persist just seems like a recipe for disaster.

Hm. Maybe I gave a false impression? They only persist, for that instance of the shell, and only until that shell instance terminates. And by that judgement, isn't the following also a potentially disasterous recipe?

c:\test>perl -de1
Loading DB routines from perl5db.pl version 1.3
Editor support available.

Enter h or `h h' for help, or `perldoc perldebug' for more help.

main::(-e:1):   1
  DB<1> $x = 12345

  DB<2> print $x
12345
  DB<3>
[download]

Because replace DB<1> with c:\test> and it is exactly analogous. And in any case, the behaviour is easily altered to your preferred option:

C:\test>path
PATH=C:\WINDOWS\system32;C:\WINDOWS;C:\WINDOWS\system32\WBEM;C:\T...
C:\test>cmd /c "set path=a load of junk here && path"
PATH=a load of junk here
C:\test>path
PATH=C:\WINDOWS\system32;C:\WINDOWS;C:\WINDOWS\system32\WBEM;C:\T...
[download]

Or when invoking a bat file you can avoid it changing the current shell instance by explicitly starting a new instance of the shell to run it as in:

C:\test>type junk.bat
set test=this is the value set inside the .bat file
c:\test>start /b junk.bat
c:\test>set test=this is the value set inside the .bat file
c:\test>set test
Environment variable test not defined
[download]

So either behaviour is easily available. And here's yet another way to choose the required behaviour:

c:\test>type junk.bat
set test1=this persists
setlocal
set test2=this does not persist
endlocal
set test3=and this persists also

c:\test>set | find "test"
c:\test>junk
c:\test>set test1=this persists
c:\test>setlocal
c:\test>set test2=this does not persist
c:\test>endlocal
c:\test>set test3=and this persists also

c:\test>set | find "test"
test1=this persists
test3=and this persists also
[download]

We could argue till we are blue in the face about which is the correct behaviour, but the reality is that these are two different systems with two different 'default' behaviours. So assuming that they are the same, or complaining that they are not is futile.

I could also argue that the Win32 behaviour is more flexible because it gives you the choice, and that there are some very definite uses for it's default behaviour. But I'm guessing you probably won't read down this far, and they would fall on deaf ears even if you do.

And that in a nutshell is my major problem with efforts like cygwin and Strawberry Perl.

• cygwin, as effective as it is at doing what it sets out to do, is for all the word like fitting a set of handlbars to a family estate car and expecting it to handle like a motorbike.

  If you want a motorbike, buy one.

• Strawberry Perl worries me exactly because it appears to have been successful in pursuading a number of key Perl contribtors to use it in preference to AS.

  Whilst I acknowledge that it has brought some benefits to Win32 users, it has set the precedent that it is becoming the defacto target for win32 development effort when most users live in the AS world. That makes for a world where many incompatibilities remain and some will not, by definition cannot, be addressed.

  It also means that by "dodging the bullet" of fixing the AS port, it removes the possibility for allowing Perl full access to some of the uniquely Win32 technologies that could really benefit Win32 Perl users.

The attempt is to make win32 look and behave like *nix so that *nix people are more comfortable and can pretend that they do not sully themselves. But in that attempt, they create more problems than they resolve. And, by the by, throw away the potential for some really good stuff.

Just as it is unlikely that I could ever get up to speed on *nix to rival the hardcore *nix Perl developers. It is, with rare exception, unreasonable to expect that many of them will get up to speed on win32 development sufficiently to exploit the full potential of Perl on Win32. The only solution I see is for pairs of people to get together from both sides to drive things forward to successfully exploit the potential from both sides. But that requires feedback.