If we want to claim Ivy compatibility, we need to expose all configuration options of the underlying resolvers. Or maybe we shouldn't wrap them but only provide factory methods. Two other options that I already missed in practice (when porting an Ant/Ivy build) are m2compatible and changingPattern. I ended up using URLResolver directly, which was inconvenient because I had to manually set the Repository.

I'm not sure that we want to be tied to being 100% compatible with ivy. Directly exposing DependencyResolver brings a whole truckload of baggage that we don't want, and 99.9% of users don't need. We're currently moving away from exposing the underlying resolvers directly, instead exposing our own DSL for defining repositories. See recent changes to mavenCentral() and the new maven() method on RepositoryHandler.

In your case, if you needed m2compatible and changingPattern, is there a reason that mavenRepo didn't work for you?

If our goal is to support Ivy repositories created not (only) with Gradle in mind, and to make it possible (and straightforward) to port Ant/Ivy builds to Gradle, then we need to stay close to Ivy resolvers and support all their configuration options. From what I've seen in the wild, having multiple Ivy repositories in the same build which differ in their values for ivy pattern, artifact pattern, m2compatible, and changingPattern isn't uncommon at all.

If our goal is to offer a Gradle repository type which just happens to be implemented using Ivy at the moment, abstracting from Ivy makes a lot of sense.

Of course we can pursue both of these goals, but then we should provide two separate APIs/DSLs. At the moment, repositories.ivy isn't a good fit for the former goal.

>In your case, if you needed m2compatible and changingPattern, is there a reason that mavenRepo didn't work for you?
I didn't try because the ivy.xml I ported over used an URLResolver and I tried to stay as close as possible to the original. However I doubt that mavenRepo is the right choice for an Ivy repo with explicitly set ivy pattern, artifact pattern, changingPattern and transitive dependency management based on ivy.xml's.