Expressão lambda e método sobrecarregando dúvidas

OK, então a sobrecarga de método é uma coisa ruim ™. Agora que isso foi resolvido, vamos assumir que eu realmentequer sobrecarregar um método como este:

static void run(Consumer<Integer> consumer) {
    System.out.println("consumer");
}

static void run(Function<Integer, Integer> function) {
    System.out.println("function");
}

No Java 7, eu poderia chamá-los facilmente com classes anônimas não ambíguas como argumentos:

run(new Consumer<Integer>() {
    public void accept(Integer integer) {}
});

run(new Function<Integer, Integer>() {
    public Integer apply(Integer o) { return 1; }
});

Agora no Java 8, eu gostaria de chamar esses métodos com expressões lambda, é claro, e eu posso!

// Consumer
run((Integer i) -> {});

// Function
run((Integer i) -> 1);

Desde o compiladordevemos ser capaz de inferirIntegerporque eu não deixoInteger embora então?

// Consumer
run(i -> {});

// Function
run(i -> 1);

Mas isso não compila. O compilador (javac, jdk1.8.0_05) não gosta disso:

Test.java:63: error: reference to run is ambiguous
        run(i -> {});
        ^
  both method run(Consumer<Integer>) in Test and 
       method run(Function<Integer,Integer>) in Test match

Para mim, intuitivamente, isso não faz sentido. Não há absolutamente nenhuma ambiguidade entre uma expressão lambda que gera um valor de retorno ("compatível com valores") e uma expressão lambda que geravoid ("compatível com o vazio"), conforme estabelecido noJLS §15.27.

Mas é claro que o JLS é profundo e complexo e herdamos 20 anos de histórico de compatibilidade com versões anteriores, e há coisas novas como:

Certas expressões de argumento que contêmexpressões lambda implicitamente digitadas (§15.27.1) ou referências inexatas de método (§15.13.1) são ignorados pelos testes de aplicabilidade, porque seu significado não pode ser determinado até que um tipo de destino seja selecionado.

de JLS §15.12.2

A limitação acima está provavelmente relacionada ao fato de queJEP 101 não foi implementado todo o caminho, como pode ser vistoaqui eaqui.

Pergunta, questão:

Quem pode me dizer exatamente quais partes do JLS especificam essa ambiguidade em tempo de compilação (ou é um bug do compilador)?

Bônus: Por que as coisas foram decididas dessa maneira?

Atualizar:

Com jdk1.8.0_40, o acima compila e funciona bem