*** Issue 160957 has been marked as a duplicate of this issue. ***

In issue # 160957, it is suggested this is not an index problem, but should be worked around on refactoring side. 
However, this means not only Change parameters will have to contain a workaround, but also Find Usages, Safely delete 
and any other refactoring provided by third parties.

Are you sure it wouldn't be better to add those synthetic members to the index?

Could you describe in more details why Safely Delete, Find Usages and any other refactoring provided by third parties
should contain a workaround please?

If you have:

public class A {
   public A() {
      //do something
   }

   public A(String s) {
      //do something else
   }
}

Trying to safely delete A() needs to check whether there are subclasses whose constructors call super() implicitly.
Find usages on A() should find the same subclasses.

The same principle applies to any other refactoring.

Any feedback on whether this is a refactoring issue or indexing issue?

Sorry for delay, I has not been on-line for a while. Here is the update:

I have been investigating the class index a bit and it seems to contain references of implicit constructors. Thus there
is nothing to fix in the index. Instead of querying for subclasses it is possible to query for constructor references
directly so your use case with safely delete will work.

For the Change Parameters refactoring nothing changes. The subclasses query should be usually faster since it skips "new
Foo()" references.

fixed http://hg.netbeans.org/jet-main/rev/9028d2d8f695

Only the main issue got fixed. The other ones mentioned in the discussion are still broken. For instance, given:

public class SuperClass {
   public SuperClass() {}
   public SuperClass(Object o) {}
}

and 

public class SubClass extends SuperClass {
}

Trying to safely delete SuperClass() should fail, but works now, leaving SubClass uncompilable. Find Usages on 
SuperClass() returns zero results, when it should point to the default constructor in SubClass. Third party 
refactorings applicable to SuperClass() will probably fail as well.

So I will mark this issue as VERIFIED, but will file two new ones.

Filed issue # 166511 (Safely delete) and issue # 165512 (Find Usages)