sorry it has taken me so long to respond to your comments – i was waiting for a JIRA notification. I'll try to check back here more frequently.
thanks for reviewing my patch. Only supporting complex paths from within Ant is definitely a major limitation. But when I looked at the amount of code that existed in Ant for parsing paths and building classloaders, I got nervous about the idea of adding so much without a good review. I'd also be worried about adding <classpath> to <ivy:settings> in a way that is different from <classpath> elements in other standard Ant tasks.
I thought that we could add support for 'path' in IvyClassLoaderManagerImpl like in Xavier's first comment. Maybe it wouldn't have to support the full Ant syntax (no automatic switching between ';' and ':', for example)?
Regarding refid: I thought in the future the "refid" syntax might be useful in more environments than just Ant. For example, when Ivy is used in Eclipse, refid could be used to refer to the name of an Eclipse User Libraries or project build paths.
Interesting to note that Maarten's second bullet point is exactly what we are doing in our build system. We try to use Ivy to load its own plugins. Thus we don't have to put plugin jars in source control, or require developers to update them manually. It is also useful to have the plugin jars in the Ivy cache instead of using a URL classloader, so that remote developers don't have to be on VPN to run the build.