Re: C'est un troll.

using System;

class MainClass
{
public static void Main(string[] args)
{
A a = new B();
B b = new B();
a.d();
b.d();
}
}

class A{
public void d(){
Console.WriteLine("Je suis une voiture");
}
}

class B : A{
public new void d(){
Console.WriteLine("Je suis une ford");
}
}

on obtient effectivement :
Je suis une voiture
Je suis une ford

Je vois effectivement ce que tu veux dire.
Le compilateur se base sur la définition stricte de a et fait dès lors exécuter d de A. Le compilateur n'a pas tenu compte du véritable type de a. Considérons une instruction if et imaginons qu'en fonction de l'évaluation de la condition, on assigne dans a soit un objet A, soit un object B. Le compilateur lui-même ne peut savoir que a contient réellement un objet B. Ce n'est qu'en cours d'exécution de programme que cette constatation peut-être faite, et, par défaut, le compilateur ne génère pas de code permettant de faire cette constatation. (sinon on aurait les même problème de perfs qu'avec les virtual)
Effectivement celà peut-être troublant, mais bon, ce n'est pas non plus vraiment génant à mon goût... celui qui développe la classe sait explicitement ce qu'il fait, il redéfini une méthode d'une classe alors que normalement il ne peut pas (elle n'est pas virtual), donc celà paraît normal qu'il ne puisse pas en modifier le comportement... Je pense que celà permet de redéfinir une méthode, et, en connaisssant le type exact on peut appeler cette version de la méthode. (pour contourner le fait que les méthodes ne sont pas virtual par défaut).
Enfin perso je me souvient pas avoir rencontrer le problème.