That looks like normal behavior. When you have the option to find reference incrementally enabled (Tools > Options > Editing > Context Tagging > References > Find reference incrementally), when SlickEdit encounters a file that contains the symbol (a string match) that references is searching for, it searches the actual occurrences and does symbol lookups in order to determine if it matches the symbol you are searching for references to (same class, etc). If nothing matches, it leaves the file in the list and marks it as having "NO REFERENCES...". This also happens if you manually try to expand a node in the references tree.
In the normal mode, files like this would still be added to the tree, but when References is initially cycling through matches, it removes the files that have no references. The reason that it leaves them behind in incremental mode and when you expand a file manually is so that you don't have tree nodes disappear out from under you when you are exploring symbol references manually.
That said, the real question is why the references in the files that show "NO REFERENCES..." do not match. I can say with certainty, it has nothing to do with spaces in directory or file names. 99% of the time, it is on account of C preprocessing making the code unrecognizable. The other 1% of the time, it has to do with C++ namespace or template resolution cases that are just plain difficult for anything but a compiler to deal with (and not easy for compilers either).
Open one of those files, look at the Defs tool window to verify that the symbols in that file are tagged as expected (including the class names), then go to one of the occurrences of the symbol you are looking for and look at the Preview tool window. If the symbol is not found, or it does not find the same symbol that you were doing references to, then the question is what does it find, and why does it find something other than what it should? Again, that usually goes back to preprocessing, templates, or namespaces. Since it looks like the code you have there is plain C, I'm going to narrow that down to preprocessing.
That's about all the help I can give you on this one without seeing the source code.
