Здравствуйте, Shmj, Вы писали:

S>Можно IEnumerable<T>, если этот список формируется динамически (yield return или прямая реализация шаблона).
S>К примеру, Directory.GetFiles() возвращает string[].

А Directory.EnumerateFiles() возвращает IEnumerable<string>.

S>...возвращает string[]. Насколько это правильно?

Это прибивает гвоздями решение аллоцировать массив менеджером памяти. Плохо для пользователей, которые пишут чувствительный к memory-трафику код.
В лучшем случае автор библиотеки это сделает через GC.AllocateUninitializedArray{T}(), но кто про него знает? А пользователь библиотеки может предоставить более эффективную для своего сценария стратегию получения массивов; скажем, через ArrayPool{T} или stackalloc.

S>Емнип, сами MS в своих Guidelines рекомендовали типа ReadOnlyCollection<T> в общих случаях.

Многие современные стандартные API и вовсе запрашивают выходной Span<string>. Правда, это требует API для предварительной оценки количества элементов, что вряд ли оправдано конкретно для списка файлов.

S>Но если он занимает место в памяти целиком — то смысла в IEnumerable нет...
S>Кто серьезно относится к этому вопросу и что делаете?

Я серьёзно отношусь к этому вопросу, и вместо GetFiles() вероятнее всего сделал бы PopulateFiles(), передавая туда ICollection<string>, или лучше TCollection where TCollection : ICollection<string>, или вовсе конкретный класс коллекции, а может и Span<string>. То есть вынести решение о стратегии аллокации наружу. Это не так декларативно, и сложнее в использовании, зато гибче. Если пользователю не нравится такой вызов и пофиг на производительность, он сможет и сам легко обернуть во что-нибудь, возвращающее массив.