Gnumake has broken PATH behavior in xcode 3.2; are others seeing this?

Question

It appears that the handling of the PATH variable is now broken in Xcode 3.2 with Snow Leopard.
As long as SHELL is still set to the default of /bin/sh, simple commands seem to now be handled differently (perhaps via a built-in optimization?) and only the pre-existing environment PATH to gnumake is used, instead of the PATH variable. This results in inconsistent behavior, where printing $PATH from the shell shows the correct path, and "which" can locate an executable, but when you try to run it, it says it can't be found.
The following Makefile demonstrates this, if you run "make test1" with the new make.
It fails, but should succeed. Meanwhile "make test2" and "make test3" succeed.
Note that if you change SHELL to something other than /bin/sh, it will work for test1,
even if what it points to is just a copy of /bin/sh named something else.
Is anyone else seeing this happen? It's odd, since the gnu version of make is the same for Xcode 3.1 and 3.2, so Apple must be making some other optimizations that affect it.
Here's the Makefile to show this:
(unfortunately, the tabs don't seem to be coming through, so you'll need to re-indent this
properly as a Makefile)
PATH := mybin:$(PATH)
export MAKE
test1: mybin/testprogram
echo SHELL=$(SHELL)
echo PATH=$(PATH)
which testprogram
testprogram
test2: mybin/testprogram
echo SHELL=$(SHELL)
echo PATH=$(PATH)
which testprogram
echo; testprogram
test3: mybin/testprogram
echo SHELL=$(SHELL)
echo PATH=$(PATH)
which testprogram
a=0 testprogram
mybin/testprogram:
mkdir -p mybin
echo "#!/bin/sh" > $@
echo 'echo "($$MAKE) has run $$0"' >> $@
chmod +x $@

Answer 1

I misquoted some details. At the time the incident occurred my Remote Desktop Administrator was the only ARD admin configured to use the task server where the data was lost from. The other 4 where not yet configured.
(the old server we are retiring (with it's own separate license had the other Remote Desktop Administrators reporting to it)
I have started switching other Administrators over to the server in question and have not seen any more systems disappear from the sqlite3 database.
I also updated our old task server to 3.3.1 on Friday and over the weekend it maintained all the data. Even for a system that has not reported any new data since September of 2006.