I have noticed this too. I can confirm that org.netbeans.modules.maven.grammar.AbstractSchemaBasedGrammar.queryElements is not producing the 'project' entry; it is coming from a org.netbeans.modules.xml.schema.completion.CompletionResultItem.

In fact if you comment out xsi:schemaLocation the bug disappears. FWIW the schema declaration of <configuration> is

<xs:element name="configuration" minOccurs="0">
  <xs:annotation.../>
  <xs:complexType>
    <xs:sequence>
      <xs:any minOccurs="0" maxOccurs="unbounded" processContents="skip"/>
    </xs:sequence>
  </xs:complexType>
</xs:element>

which does not rule out <project> as a possible child element, of course, but certainly does not suggest it (or anything else for that matter).

I think CompletionUtil.substituteAny is at fault: it should add no completion items when anyNamespace.equals("##any"); and the other clauses should be considered carefully as well, especially anyNamespace.equals("##other").

(In reply to comment #1)
> I think CompletionUtil.substituteAny is at fault: it should add no completion
> items when anyNamespace.equals("##any"); and the other clauses should be
> considered carefully as well, especially anyNamespace.equals("##other").

I think that (as you point out), the schema doesn't define the content of configuration adequately. The benefit of them having anyElement is that they can avoid forcing definers of <configuration> content to use a substitutionGroup (as they would need to if the pom schema restricted the content to, e.g., <config-element abstract="true"/>). This comes at the cost of making the definition too lax.

These kinds of situations (with inappropriately broad suggestions) in XML documents are analogous to situations like Collection.add(Object) in Java. Inasmuch as it satisfies the compiler, any suggestion is appropriate (as any type extends Object),  and the IDE is correct in supplying all suggestions. The IDE is also correct in highlighting "suspicious" usages of Collection.add() in which the added object's type does not match the generic type of the Collection. So, it seems that the Collection API is to blame (for not restricting the method to List<T>.add(T)). In the same way, I think the schema is to blame for the extra suggestions. 

So, I think CompletionUtil is doing the right thing. To make completion more usable, I think we can learn lots from the Java completion. For example, we could restrict initial suggestions, and force the user to invoke completion again for _all_ suggestions (including things like xsi:schemaLocation when <anyAttribute/> is used). We could also perhaps add warnings if there are situations like this one, where the usage is technically valid, but suspicious (like recursive use of <project> in <configuration>). That way, we enable service providers (schema writers) to express themselves through the schema by honouring the schema definition. We also ease the burden on the user of the inappropriately broad schema by adding extra editor features.

TL;DR: I'm happy to close this: in my mind, the schema is at fault.

I guess you are talking about Collection.remove. The analogy does not really hold because the schema is correct - a POM schema cannot statically know what configuration plugins might take - but one module in the IDE is already offer useful dynamic completion items, whereas a more generic module is offering a pointless item.

This old bug may not be relevant anymore. If you can still reproduce it in 8.2 development builds please reopen this issue.

Thanks for your cooperation,
NetBeans IDE 8.2 Release Boss