Based on experience, returning Stream<Concern> is probably overkill and a bit bulky for ConcernProvider.concerns() and for other Csar methods. It might be simpler just to use Set and Iterable as appropriate. (Stream was probably used in over-eagerness when streams were introduced in Java.)
For ConcernProvider.getConcerns(), I considered returning a set, but there is no guidance about what makes a Concern "equal", so it's probably just as well not to quibble and return one of the lowest denominators, an Iterable. Most of these providers only return a single concern, anyway.
There are so many arguments about whether to return streams or iterables/collections, with Brian Goetz making good arguments to return streams, and Joshua Bloch in Effective Java, Third Edition, Item 47 arguing to prefer collections. And I did notice in ConcernedThreadGroup that passing a stream to the constructor is really helpful in collecting the concerns to a map.
After further consideration, there may be a subtle semantic difference between a "provider" that produces some list of things (e.g. a ConcernProvider here) and some other service such as a ResourceBundleLoader, which indicates some finite set of things (e.g. filename extensions) it support. For a provider, returning a stream of things it "provides" may in fact be semantically the best choice, especially if the caller might want to sort through them somehow. But for ResourceBundleLoader.getFilenameExtensions(), a set might be more appropriate. The latter isn't "producing" or "providing" filename extensions, but instead indicating a finite set which it supports.
So I think I'll go back to returning a Stream<Concern> for ConcernProvider.concerns().