I'm sad to hear that you want to hide Ivy even more. For me, the biggest selling point of Gradle is its use of Ivy, a proven and flexible system that I like very much. If I were you I would embrace it instead, so that I could say with confidence that Gradle indeed knows everything that Ivy does, and more. But I guess this is not up for debate and I'm sure you have your reasons.
However, you saying that exposing Ivy is a dead end, confirms that we should not go with Gradle. It is that very customizability that Ivy offers that enables our use of Gradle. We wrote a custom Ivy resolver for our internal repository, we created an Ivy module descriptor parser for our descriptor format, we plugged in our own Ivy message logger, we would want to use a custom conflict resolver and version matcher to deal with our versioning scheme, and so on.
But to reply to you, I agree that some built in conflict resolution strategies would be sufficient for most. Besides the latest and the no-conflict strategy, a compatible strategy (for some notation, for example 1.2.+) is often used.
It might belong to a Configuration logically, but then again, I hardly see a case where you would use two different strategies for two configurations in the same build. It might simplify the build script if you only have a single universal resolution strategy. Also, if you assign it to configurations, you have to think about what should happen when a configuration extends another with a different strategy. I mean not just you, but the user too.