params перегружает очевидную двусмысленность - все еще компилируется и работает?

Это явно ошибка в разрешении перегрузки.

Он воспроизводится в C# 5 и C# 3, но не в Roslyn; Я не помню, намеренно ли мы решили взять мелочь или это случайность. (Сейчас на моей машине нет C# 4, но если он воспроизводится в 3 и 5, то почти наверняка будет и в 4.)

Я обратил на это внимание моих бывших коллег из команды Roslyn. Если они вернутся ко мне с чем-нибудь интересным, я обновлю этот ответ.

Поскольку у меня больше нет доступа к исходному коду C# 3/4/5, я не могу сказать, в чем причина ошибки. Сообщите об этом на сайте connect.microsoft.com.

Вот сильно упрощенное воспроизведение:

class P
{
    static void M(params System.Collections.Generic.List<string>[] p) {}
    static void M(params int[] p)  {}
    static void Main()
    {
        M();
    }
}

Похоже, это как-то связано с универсальностью типа элемента. Как ни странно, как указывает Крис в своем ответе, компилятор выбирает более общий вариант! Я ожидал, что ошибка будет другой, и выбрал менее общую.

Ошибка, кстати, скорее всего, моя вина, так как я проделал изрядную часть работы над алгоритмом разрешения перегрузок в C# 3. Приносим извинения за ошибку.

ОБНОВИТЬ

Мои шпионы в команде Roslyn говорят мне, что это известная давняя ошибка в разрешении перегрузок. Было реализовано правило разрешения конфликтов, которое никогда не было задокументировано или обосновано и гласило, что тип с большой универсальной арностью является лучшим типом. Это странное правило без каких-либо оправданий, но оно никогда не удалялось из продукта. Некоторое время назад команда Roslyn решила внести критическое изменение и исправить разрешение перегрузки, чтобы в этом случае она выдавала ошибку. (Я не помню такого решения, но мы приняли много решений по такого рода вещам!)

В IDEONE компилятор успешно выдает ошибку. И это должно быть ошибкой, если пошагово разобрать алгоритм разрешения:

1) Набор методов-кандидатов для вызова метода построен. Начиная с набора методов, связанных с M, которые были найдены при предыдущем поиске элемента [...] Сокращение набора состоит в применении следующих правил к каждому методу TN в наборе, где T - это тип, в котором метод N объявляется:

Для простоты мы можем сделать вывод, что набор методов здесь содержит оба ваших метода.

Затем продолжается сокращение:

2) Если N неприменим в отношении A (Раздел 7.4.2.1), то N удаляется из набора.

Оба метода применимы в отношении Applicable function member правила в их расширенной форме:

Расширенная форма создается путем замены массива параметров в объявлении члена функции нулем или более параметрами-значениями типа элемента массива параметров таким образом, чтобы количество аргументов в списке аргументов A соответствовало общему количеству параметров. Если A имеет меньше аргументов, чем количество фиксированных параметров в объявлении функции-члена, расширенная форма функции-члена не может быть создана и, следовательно, неприменима.

Это правило оставляет оба метода в редукционном наборе.

Эксперименты (изменение типа параметра id на float в одном или обоих методах) подтверждают, что обе функции остаются в наборе кандидатов и дополнительно различаются по неявные правила сравнения конверсий .

Это говорит о том, что приведенный выше алгоритм отлично работает с точки зрения создания набора кандидатов и не зависит от какого-либо внутреннего порядка методов. Поскольку единственное, что различает методы, — это разрешение перегрузки правила похоже, это ошибка, потому что:

лучший член функции — это член функции, который лучше всех других членов функции в отношении заданного списка аргументов, при условии, что каждый член функции сравнивается со всеми другими членами функции с использованием правил в Раздел 7.4.2.2.

и очевидно, что ни один из этих методов не лучше других, потому что здесь не существует неявных преобразований.

Это не полный ответ, поскольку он объясняет различия, но не почему. Для полноты действительно нужна ссылка на спецификацию. Однако я не хотел, чтобы исследование, которое я провел, потерялось в комментариях, поэтому я публикую его как ответ.

Разница между двумя перегрузками заключается в том, что параметры для одной являются общими, а для другой — нет. Компилятор, кажется, решил, что общий тип ближе, чем не универсальный.

То есть, если тип Expression<...> был изменен на int, компилятор будет жаловаться на двусмысленность. Аналогично, если оба типа являются общими, тогда он жалуется на двусмысленность.

Следующий фрагмент демонстрирует это поведение более просто:

void Main()
{
    TestMethod();
}

public void TestMethod(params string[] args)
{
    Console.WriteLine("NonGeneric");
}

public void TestMethod(params List<string>[] args)
{
    Console.WriteLine("Generic");
}

Это напечатает «Универсальный».