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.