The consensus on the Gradle dev list is that this is just a manifestation of the limitation of Maven design, here specifically the limiting to pre-defined "scopes". In fact, even Maven's own documentation points out how fubar this particular limitation is in exactly this situation/regard
http://maven.apache.org/guides/introduction/introduction-to-dependency-mechanism.html

(see the footnote to the transitivity table)

Anyway, Gradle team have agreed that since a POM is a Maven artifact it ought to follow Maven "principles". So they will change the new Maven Publishing code to use compile scope (rather than runtime scope) for dependencies it writes to the POM.

In the meantime, I have hacked this to change the scopes in the pom by brute force

That specific one sure seems like a bug in the antrun plugin Christian. Why would the antrun plugin not pull in all runtime scope dependencies for the specified dependencies? Its about ready to run it...

Breaks for example InstrumentTask setup:

Dependencies for this before the change:

Now:

How is this "breaking lots of (any) builds"?