I also noticed this problem when I tried to run the regression suite.
The test case to reproduce is:

public void testSettings() throws Exception {
        Project p = openProject();
        DataObject modified = null;
        
        try{
            DataFolder doFolder = projectFolder;
            modified =
DataObject.find(doFolder.getPrimaryFile().createData("modified",
"xxx"));
            ProjectObject[] pos = new ProjectObject[]
{p.getProjectObject(modified)};
            ProjectObject btpo = getBuildTarget("bt1", p);
            t test = new t(btpo);
            String s = "123";
            test.setProperty(s);
            Object s2 = test.getProperty();
            if (s2 == null) {
                fail("cannot set property");
            }
            
        } finally {
            if (modified != null) {
                modified.delete();
            }
        }
    }
    
    static class t extends org.netbeans.api.projects.ContextSettings { 
        private static final String TS = "usedep-ts";
   
         t(ProjectObject buildTarget) throws
javax.naming.NamingException {
            super(buildTarget.getContext());
         }
         
         public void setProperty(Object p) {
            putProperty(TS, p, Scope.PERSONAL, true);
         }
         
         
         public Object getProperty() {
             return getProperty(TS, null);
         }
    
    }

Cause of problem know (I think).

The first problem was that the parameter to rebind() wasn't
using the prefixed name, it was using just the base name.
This meant the settings files on disk could clash, and lookup
wasn't looking for what was written to disk.

Second, the files written to disk are "escaped", e.g. it
doesn't create "org.netbeans.foo", it creates a file named
"org#002Enetbeans#002Efoo"
So we need to perform a similar translation when looking for
the settings files. (InstanceDataObject).

I verified this by getting rid of the extra "." appended
by ContextSettings' prefix constructor, and passing in a
simple prefix without any special characters like dot - then
everything worked.  (By the way, I don't think the system
should append a dot to a client-specified prefix; it's
unnecessary and "violates" the prefix intended by the
client: if I state that I want "PRE" as a prefix for all
my settings, I expect "PREsetting", not "PRE.setting".)

Fixed. I first fixed it by lobotomizing the new
"prefix" code in property notification, then
yesterday I restored it with some additional code -
here's the putback message:

Reinstate prefix functionality; modify the prefix code to
generate prefixes which do not get altered by the 
InstanceDataObject. Also add warning-checking code for
module-supplied prefixes. Also filed #27494 to track
this issue for core.naming.
 [core/naming] JNDI problems when names >= 50 chars or contain
   nonalphanumeric chars

Verified

As described in
http://www.netbeans.org/servlets/ReadMsg?msgId=619519&listName=nbdiscuss the
current work on projects prototype has been stopped.

Marking issue as CLOSED.