My initial implementation had an url and urls parameter. But as far as I can remember Steve, Russel and Adam voted for the urls only approach. We had some discussions about this. But I like your reasoning regarding forcing someone to learn an advanced concept. I will reopen the discussion about this after 0.8.

My worry was that we had two attributes: url that took a string, and urls that took a list of strings. I felt a user would feel (as I did) annoyed that she had to deal separately with separate data types – Groovy is, after all, a dynamic language with polymorphism and so we should expect Gradle to deal with a single attribute having different types.

Having moved to a single attribute that can process strings or lists of strings, I am not that worried about the singularity or plurality of the label of the attribute: I feel the distinction between url and urls is not actually that important.

Being able to pass the URL or list of URLs as an unnamed parameter is though something I would support as a good feature for this function.

>Having moved to a single attribute that can process strings or lists of strings, I am not that worried about the singularity or plurality of the label of the attribute: I feel the distinction between url and urls is not actually that important.
Not remembering the exact syntax, I immediately tried the unnamed and "url" variation. As both failed, I looked up the syntax in the documentation, was confused by the plural form, read further to make sense of it. Minutes later, I added one "s" to the build script and it suddenly worked.
Actually, it's quite common in Java to use the singular form for an annotation value of array type, especially if a single value is the main use case. An unnamed parameter would be equally fine, provided it is considered a fit for Gradle's DSL style.