Как видите, обе функции принимают IEnumerable<>, но вызывающая сторона не знает, как реагируют функции.

Это просто вопрос документации. Ознакомьтесь с документацией по DistinctBy в MoreLINQ, которая включает:

Этот оператор использует отложенное выполнение и передает результаты, хотя набор уже просмотренных ключей сохраняется. Если ключ встречается несколько раз, возвращается только первый элемент с этим ключом.

Да, важно знать, что делает участник, прежде чем использовать его, и для вещей, принимающих/возвращающих любые коллекции, есть несколько важных вещей, которые нужно знать:

• Сборник будет прочитан сразу или отложен?
• Будет ли коллекция передаваться в потоковом режиме во время возврата результатов?
• Если объявленный принятый тип коллекции является изменяемым, попытается ли метод изменить его?
• Если объявленный возвращаемый тип коллекции является изменяемым, будет ли он действительно изменяемой реализацией?
• Будет ли возвращенная коллекция изменена другими действиями (например, это доступное только для чтения представление коллекции, которое может быть изменено внутри класса)
• Является ли null приемлемым входным значением?
• Является ли null допустимым значением элемента?
• Будет ли метод когда-либо возвращать null?

Все эти вещи заслуживают внимания, и большинство из них стоило рассмотреть задолго до появления LINQ.

Мораль на самом деле такова: «Убедитесь, что вы знаете, как что-то ведет себя, прежде чем называть это». Так было до LINQ, и LINQ не изменил этого. Он просто представил две возможности (отложенное выполнение и потоковую передачу результатов), которые редко присутствовали раньше.

Используйте IEnumerable везде, где это имеет смысл, и безопасно кодируйте.

Как указал SLaks в комментарии, отложенное выполнение было возможно с IEnumerable с самого начала, а поскольку в C# 2.0 появился оператор yield, было очень легко реализовать отложенное выполнение самостоятельно. Например, этот метод возвращает IEnumerable, который использует отложенное выполнение для возврата некоторых случайных чисел:

public static IEnumerable<int> RandomSequence(int length)
{
    Random rng = new Random();
    for (int i = 0; i < length; i++) {
        Console.WriteLine("deferred execution!");
        yield return rng.Next();
    }
}

Поэтому всякий раз, когда вы используете foreach для перебора IEnumerable, вы должны предполагать, что между итерациями может произойти что угодно. Это может даже вызвать исключение, поэтому вы можете поместить цикл foreach внутрь try/finally.

Если вызывающий объект передает IEnumerable, который делает что-то опасное или постоянно возвращает числа (бесконечная последовательность), это не ваша вина. Вам не нужно обнаруживать это и выдавать ошибку; просто добавьте достаточное количество обработчиков исключений, чтобы ваш метод мог очиститься после себя, если что-то пойдет не так. В случае чего-то простого, например Shuffle, делать нечего; просто позвольте вызывающему абоненту справиться с исключением.

В редком случае, когда ваш метод действительно не может работать с бесконечной последовательностью, рассмотрите возможность принятия другого типа, такого как IList. Но даже IList не защитит вас от отложенного выполнения — вы не знаете, какой класс реализует IList или какое колдовство он проделывает, чтобы придумать каждый элемент! В очень редком случае, когда вы действительно не можете разрешить выполнение какого-либо неожиданного кода во время итерации, вы должны принять массив, не какой-то интерфейс.

Отложенное выполнение не имеет ничего общего с типами. Любой метод linq, использующий итераторы, потенциально может отложить выполнение, если вы напишете свой код таким образом. Select(), Where(), OrderByDescending() например. все используют итераторы и, следовательно, откладывают выполнение. Да, эти методы ожидают IEnumerable<T>, но это не значит, что проблема IEnumerable<T>.

То есть определенные (пользовательские) функции не согласуются с идеей Linq об отложенном выполнении. Проблема не только в производительности, но и в неожиданных побочных эффектах.

Итак, какие общие меры предосторожности вы, ребята, принимаете здесь?

Никто. Честно говоря, мы используем IEnumerable везде, и у нас нет проблем с тем, что люди не понимают «побочных эффектов». «Идея отложенного выполнения Linq» играет центральную роль в ее полезности в таких вещах, как Linq-to-SQL. Мне кажется, что дизайн пользовательских функций не так ясен, как мог бы быть. Если люди пишут код для использования LINQ и не понимают, что он делает, то проблема в этом, а не в том, что IEnumerable является базовым типом.

Все ваши идеи — это просто обертки вокруг того факта, что у вас есть программисты, которые просто не понимают linq-запросы. Если вам не нужно ленивое выполнение, которое, похоже, вам не нужно, просто заставьте все оценивать до выхода из функций. Вызовите ToList() для ваших результатов и верните их в согласованный API, с которым потребитель хотел бы работать — списки, массивы, коллекции или IEnumerables.