While ReadOnlyCollection<T> may be fine for "managing" a read-only collection, I don't think it a good choice for exposing a read-only collection. For one thing, ReadOnlyCollection<T> implements IList<T>, which, of course, has methods/properties for modifying the collection.wkempf said:1. There's other "readonly collection" types. ReadOnlyCollection<T> for instance. It's not always appropriate to expose IEnumerable only because you want a "readonly collection" type.
2. IEnumerable<Foo> isn't the ugly syntax you want to make it out to be. Foo* or Foo+ may be shorter, but they are also less meaningful. I think it was at least a little questionable that we added the Foo? syntax, when this is nothing but sugar for Nullable<Foo>. My gut tells me it's even more questionable to do the same in this case. Obviously that's only an opinion.
Another point in favor of IEnumerable<> that I forgot to mention is flexibility. In other words, you're able to change the implementation later on and perhaps choose a different underlying container.
I'm not sure what you mean when you say "...they are also less meaningful...". Why? If you program in C#, then you are very accustomed to using symbols to refer to various concepts. Even terms like "object" and "int" are really symbols representing some "real" type. I'm proposing that there be a symbol that means "some number of things".