I think I lean towards the `List<String>` as yaml makes it possible to supply that as config and it gives us type correction. But it implies two areas where things get more complex:

* Distinguishing between *add* to a list and *set* the list (clear-and-add); my thinking was to add some stuff in the `$brooklyn` dsl for yaml to access `ListModifications` / `MapMods` though still not sure exactly how best to handle this

* When you want to supply classpath entries from the CLI or other context which doesn't support lists; note I *think* this is possible already using something like `brooklynnode.classpath.1=entry1` and `brooklynnode.classpath.2=entryB` (and could also support `brooklynnode.classpath.3=entryC;entryD` depending how you handle entries in the list) -- any segment after the `brooklynnode.classpath.` is taken as defining a map which generates the list, but that codepath hasn't been tested

So I'm weakly in favour of trying to find a way to support lists and strings (even if it ends up being a whole new config key `brooklynnode.classpathLine` where you take both, but ideally one of the comments above can be cleaned up).  Failing that mark it `@Beta` and being prepared to deal with changes.