I used it many time, it seems ok. So let's resolve it as fixed.

I have implemented what I described in my last comment.
I am not very sure about the correctness of the implementation regarding the wizard creation, it doesn't seems to be well supported by the JDT API. Any feedback on this will be appreciated.

Here is what I am willing to implement unless there are some objections:

• an IvyDE classpath container will be unique by ivy.xml and conf:
  • having ivy.xml[*] configured and trying to add ivy.xml[*] will fail
  • having ivy.xml[default] configured and trying to add ivy.xml[test] will be sucessfull
  • having ivy.xml[*] configured and trying to add ivy.xml[test] will fail
• the "add library" action will not just add a container, it will open the wizard of creation of the container with its fields being already filled. So instead of one click there will be two, but it is less than the 3+ clicks needed by the classical "Add library" workflow.

Note: I didn't include the ivysettings and properties in the "uniqueness" check of the IvyDE classpath container in a project: it seems to me too weird to have the same ivy.xml and same conf used with just some different settings.

Yes, it is a normal use case to have multiple ivy classpath containers. With web applications it is necessary to have different directories for runtime, tool and test classpaths. So I would guess that there is no need to create a warning of multiple ivy classpath containers.

I use multiple classpath containers for main dependencies and test dependencies so they're visually separated in the package explorer.

What about issuing a warning that another classpath container already exists?

This should fix any confusion issues and still allow advanced uses cases.

True, someone might want to have multiple classpath containers with different configurations.

Actually I can still do it.
But then I don't know if it is a bug or a feature, should we allow sevral IvyDE classpath container in the same project ?
If we allow different container with different resolved configuration, should we support different container with just a different order of classpath entries ?

With the version from SVN this is no longer reproducible.

A quick fix that is based on 2nd segment being the ivy classpath identifier.