Por que o Reverse virou void no build sem eu mudar o código?

Tem um tipo de falha que assusta qualquer time de manutenção: o build quebra sem ninguém ter alterado aquela linha de código aparentemente inocente. O caso parecia banal:

using System.Linq. public byte[] DoAThing(byte[] input)
{ return input.Reverse().ToArray(). }

Em uma máquina compila. No servidor, o build começa a dizer que Reverse() retorna void. ## Onde mora a pegadinha Quando a toolchain mais nova entra em cena, o binding pode passar do Enumerable.Reverse() para o MemoryExtensions.Reverse() em Span<T>, que faz a reversão in-place e retorna void. Em outras palavras: não é que o método “mudou de assinatura” no seu branch. é que o compilador passou a escolher outra extensão por causa da combinação entre SDK, linguagem e framework alvo. ## O que esse caso ensina - Misturar SDK novo com target antigo pode produzir falhas bem contraintuitivas

• LangVersion=latest parece inocente, mas cria build dependente da máquina


• Em código legado, chamar Enumerable.Reverse(input) explicitamente às vezes é a saída mais honesta O que mais me chamou atenção nessa discussão foi como o problema parece ser de API, quando na verdade é de toolchain e governança de build. Como vocês têm controlado isso em times com múltiplos targets e scanners rodando em pipelines diferentes?