* I would replace the title by : "In a hierarchy of classes, method signatures should not differ only based on fully qualified names"
* The compliant solution is for me misleading because according to this solution having a doSomething() method taking a fruit.Pear parameter was done on purpose. The same way, I would remove the following sentences from the description: ""If the intent is truly for the child class to handle the same-name object from another package, then the method should be renamed to prevent confusion. Otherwise the import or fully-qualified class name should be corrected.
\[~freddy.mallet] I've updated the title, but your second point is in my mind the point of the rule - if you need to deal with a class that differs only by package, you must make it explicit & must not make the method _look_ like an override.
When this pattern occurs [~ann.campbell.2], I would bet that in 99% of the time this is not done on purpose and this is really a bug (to have imported the wrong class). With your example [~ann.campbell.2], I've the feeling that you're covering the remaining 1% -> done on purpose to import another class with exactly the same method signature.
\[~tamas.vajk] this rule is related to FxCop's DoNotDecreaseInheritedMemberVisibility but doesn't cover quite the same ground (I don't think you _can_ decrease visibility in an override in Java). Do you want to expand the scope slightly for C# & map this?
\[~ann.campbell.2] I think C# shouldn't be targeted by this rule. In C# you can't accidentally override or accidentally not override a method. You need to use the ``++override++`` keyword, and not just simply use the same signature. The FxCop rule says that if you are not overriding but redefining a method you should still not decrease the visibility.
