Thanks for asking - very good question. We should actually put this information in the API.
There are number of things we don’t like about the ResolvedConfiguration API. ResolvedConfiguration/ResolvedDependency types have some questionable methods in the API, ResolvedDependency isn’t really node in the dependency graph but rather a part of ivy resolved configurations graph, etc. ResolutionResult API will replace ResolvedConfiguration/ResolvedDependency API at some point. Don’t worry, though, it’s nothing that will happen fast - it will be a slow, backwards-compatible evolution. Right now, ResolutionResult API does not contain all the information that ResolvedConfiguration has. However, it does contain some extra stuff that should be really useful (information about the requested versions, the reason a version was selected, etc.). Also keep in mind that the new API is still @Incubating, it will change slightly before 1.3.
Your use case is very interesting. At some point we would probably want to have a higher level abstraction over exactly this use case.
Can you tell me if you could use the new API to acquire the information you need before publishing poms?