This appears to be similar to the Javadoc issue mentioned in bug 198563.  If a project that is listed as being part of the libraries for a project is listed via a share path in Windows, instead of via a drive letter, no changes to that project will be seen by the project that depends on it.

How to reproduce:

To reproduce this simply open a main project and a library project that the main depends on.  In my case I opened the library project via the drive letter.

In the main project Properties, under the Libraries, list the library project in the Library settings - but by a share pathname (\\MyDocuments\yourID\NetbeansProjects\library for example).  Now make a change to the library project source code by adding a new class or a method.  If you try to reference the new class or method it will show as an unknown class or symbol.

Workaround:
Remove the entry under Libraries and add it using the drive letter and everything will be good.

I did not test if it worked fine if both library definition *and* project were named via a share path, but it might.  It is quite possible that it is the "different" paths (one via share path and the other via drive letter path) that has caused this problem.

Unfortunately for me the My Documents at work defaults to the share path and not the drive letter.  I am in the habit now, because of 198563, to opening my projects using the drive letter.  However, many of them that defined a dependent project under libraries I did before I knew that was an issue, so they are defined using the share path.

Other than issuing a warning dialog about using a share path when opening a project or defining a library dependency I am not sure there is a way to "fix" this.  A warning dialog would at least make people aware of the issue, similar to what was proposed for the Javadoc issue in bug 198563.