Not a fix for the problem, but here is how I deal with the development / test issue:
Code:
$=SetOption("Explicit","ON")			; Sanity check for variable names.
$=SetOption("WrapAtEOL","ON")			; Wrap lines at console margins rather than truncating.
 
Global $__DEVELOPMENTDIR
$__DEVELOPMENTDIR=@HOMESHR+"\Dev\LoginScripts"
 
If Not IsDeclared($__ROOT)
	GLOBAL $__ROOT								; Path to installation
	$__ROOT=Left(@STARTDIR,InStrRev(@STARTDIR,"\")-1)
EndIf
 
; Allow diversion to development instance.
If IsDeclared($__DEVELOPMENT)
	If $__DEVELOPMENT=1 AND Exist($__DEVELOPMENTDIR+"\Dev\Login\LoginScripts\"+@SCRIPTNAME)
		$__DEVELOPMENT=0
		$__ROOT=$__DEVELOPMENTDIR+"\Dev\Login"
		CALL $__ROOT+"\LoginScripts\"+@SCRIPTNAME
		Quit @ERROR
	EndIf
EndIf
 
If Not IsDeclared($__DEBUG)			; Allow debug to be set from command line
	GLOBAL $__DEBUG						; Generate additional info.
	$__DEBUG=0								; Default is no debugging info
EndIf


As you can see, I do it by setting variables on the command line.

$__DEVELOPMENT is a boolean, set to true if I want the script to run the dev version. If it is set the script will try to find a copy of itself with the same name in the dev tree, and if it finds one it will launch that version instead ($__DEVELOPMENT is reset to ensure that the dev script doesn't call itself in an endless loop!). In my environment $__DEVELOPMENTDIR is set to a subdirectory of @HOMESHR which allows different staff to try things out without fear of clashing.

$__ROOT can be set to force the currently script to look for support libraries and files other than in the directory that it was started in.

$__DEBUG if set outputs debugging information. The higher the value that it is set to the more debugging output.

The benefit of using variables like this is that they can be set on an individual login, and you can test the script within the live environment without affecting other users.