Господа, здесь работает перегрузка, а не полиморфизм.
Право  - даже странно, что Вы пытаетесь применить полиморфизм к данному случаю. 

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

А запрещать компилировать класс Test нельзя, потому что он может быть в другом, уже откомпилированном пакете, и откомпилировать его мог кто-нибудь другой. А Вы вдруг ему из будущего запрещаете компилировать. Нарушаются базовые причинно-следственные связи! 

Добавлено через 9 минут и 48 секунд

А да точно, Вы правы. Я почемуто не заметил. Я думал под словом полиморфизм, слово перегрузка.

ЗЫ. Я вообще щитаю, что термин "перегрузка" не правильно придумали. Под словом "перегружать" ассоциируется что-то, что нужно заменить, чтобы старое определение изчезло, ну или что-то в этом духе. Можно былобы термин "перегрузить" сделать синонимом к термину "переопределить реализацию базового метода в доченем классе". А вместо "перегруженный метод" говорить "одноимённый метод" - сразу всё чётко ясно и понятно становиться. После таких рассуждений я начинаю понимать зачем появился язык Эспиранто"

Логика не такая уж и простая. При ней надо запрещать такое:

И что мы тогда получаем? В случае, если нам требуется различный код обработки различных объектов, придётся писать if по instanceof. Имхо, различные методы в данном случае удобнее.



Другой пакет в таком случае не мог быть откомпилирован. Если же класс был изменён - перестаём компилировать Test по уже названной причине и отрываем ноги такому "изменятелю". Лучше сразу по самую шею. Нефиг нарушать свои же принцыпы - "но только так, чтобы не запутать пользователя". Нефиг вызывать то, чего нет. Пытаешься - по кумполу и в канаву.