While Mattias and I were implementing this, there were a few things we realized would probably come up as requests in this thread sooner or later. I'll go ahead and list them right away:
Compound uniqueness
The ability to add something to an index with multiple key/value mappings and have the combination of these mappings form a unique mapping. Example:
index.putIfAbsent( tobias, {"first name": "Tobias", "last name": "Lindaaker"} );
Where it would be possible to have many nodes with the first name "Tobias", and many nodes with the last name "Lindaaker", but only one with that combination.
We would need some object representing that group of key/value pairs in order to support such operations.
The simplest idea is to just use a java.util.Map, but that would require reconstructing the internal query-object multiple times, it would be nice if some object could be pre-constructed and reused in between invocations to get() and putIfAbsent().
Unique relationships for a given (pair of) node(s)
This isn't really an index feature, but something that comes to mind when discussing uniqueness.
What it is is a shortcoming in the REST API. There is no way in the REST API today to create a single relationship, failing if one already exists. In the embedded API this is possible today, since creating a relationship locks the nodes you create the relationship between. Even if those locking semantics should change in the future it would still be possible to explicitly lock the node(s) to ensure such semantics. That is not possible in the REST API today (unless you want to write a plugin).
The reason this is related to indexes is because many people today use indexes for some relationships in order to avoid loading all relationships for a few heavy nodes in their database.
The reason I bring this up is because I want to say that I think solving this in indexes is wrong, better would be to solve this in the REST API, around where and how relationships are created. As for the (separate) issue of loading only a subset relationships for nodes with a (very) high degree, that is being worked on and will be resolved separately on the appropriate level.
Cheers,
Tobias