Interesting question. I expect you're already aware of how we can get the value of an environmental variable thanks to the GetEnviron method of %SYSTEM.Util

USER>w $system.Util.GetEnviron("TEMP")
C:\WINDOWS\TEMP
USER>

Maybe someone else knows how you can amend one. But if it's not possible, can you improve readability in your code by concatenating the components of your $ZF argument in several stages into a local variable, then passing that variable as the argument to $ZF ?

No, I don't think you have to switch over to the new paradigm until you're completely ready to (e.g. no-one using Studio anymore). Instead, follow Dmitry's steps, creating an Atelier project containing any of the classes that you want to edit. Don't hook the Atelier project up to an Eclipse source control provider; your namespace and the existing server-side source control class should continue to function the way it always has done.

This is how we anticipate existing users of our Deltanji (formerly VC/m) source control product will deal with the introduction of Atelier.  And perhaps not just existing users, seeing as Deltanji is available as a free Solo edition.

Dmitry's answer should be what you need. I'd add that the paradigm shift between Studio and Atelier can take a little getting used to. With Studio we're accustomed to thinking of the code in a namespace as the "source of truth". We pull the code from there, change it, and push it back in order to store our changes (and to run the amended code). With Atelier we're more likely to be pulling code into our local filesystem using a source control provider, then editing it, saving it to our local filesystem, and eventually pushing it from there back to the source control repository. Using this mode of working, we only push it into a Caché namespace in order to run/debug it.

Indeed. Presumably the "load and delete" defaults were a design decision based on the model of running unit tests elsewhere. That seems relevant for a build server, but not so friendly for the developer who you're trying to persuade to code the tests in the first place. Yes, Studio the source control hook facility can be your friend here provided you're prepared to spend enough time getting intimate with it.

Re your Atelier issue, does the "Configure server" link lead you to somewhere you can test the connection? Make sure that your Atelier connection is pointing to the port that your Cache Portal also goes to, and not to the port that your Cache Studio uses. That was an early gotcha for me in Atelier.

The Cache username that you connect with might not have enough privileges. One way to determine if this is you problem is to grant the user the %All role temporarily.