Override a serialized variable from a parent class?

What I've got now, is, in the base class:

[HideInInspector] [SerializeField] protected Button button;

...and in the derived class:

[HideInInspector] [SerializeField] RecalibrateButton _button;
_button = button as RecalibrateButton;

I'd rather do

[HideInInspector] [SerializeField] new RecalibrateButton button;
button = base.button as RecalibrateButton;

...but while that doesn't generate an error when I save the script, this error comes up shortly thereafter in the Editor:

Same name multiple times included:::Base(MonoBehaviour) button

Is there some way I can use the variable name "button" to override what the base class's "button" is?

Edit: UnityAnswers proves only abysmal ability to respond to answers, so here's what I'm doing now, in the derived class:

public override void InitializeAtRuntime () {
    base.InitializeAtRuntime();
    RecalibrateButton button = base.button as RecalibrateButton;
    button.ReleaseInsideRange += OnReleaseInsideRange;
    button.ReleaseOutsideRange += OnReleaseOutsideRange;
}

As SpikeX said - you can simply assign objects of a subclass to variables of the parent class. But obviously, there's a problem with that because you can't directly access the members that the subclass defined. So, if for example your Button has AButtonMethod() and RecalibrateButton has ARecalibrateButtonMethod(), the only way to access the latter is by doing a typecast:

((RecalibrateButton)button).ARecalibrateButtonMethod();

That's not exactly convenient, but it works. However, if RecalibrateButton overrides a method, e.g. if it has it's own definition of AButtonMethod(), the oo-runtime will automatically execute the version of RecalibrateButton when you call it. So, you might consider not creating ARecalibrateButtonMethod() when you could also override AButtonMethod(). But if that doesn't work in your specific design, you'll have to fallback to the typecast approach. One thing that I do frequently in such cases is adding a property that handles this for me (just a matter of convenience and cosmectics):

public RecalibrateButton RecalibrateButton {
    get { return (RecalibrateButton) button; }
}

That way, you can conveniently access "button" as if it was a RecalibrateButton.

No. That's the point of deriving from classes, the derived class inherits everything from its parent classes (everything that's public and protected, anyway). What you can do, though, is something like this, inside the constructor or elsewhere:

button = new RecalibrateButton();

since the "RecalibrateButton" is of type "Button", you can instantiate it, and the "button" becomes a "RecalibrateButton", even though it was defined as a "Button". So you don't need to redefine "button" at all (in fact, don't!), instead, just create an instance of the child class inside of it.

Polymorphism - What fun :)

Your code is legal C#, and in my game I can get it to work if the class is not a MonoBehaviour. (Although I have not tested it with SerializeField). This makes it look like the reflection used by MonoBehviour to build inspectors, etc., might be the reason it is flagged.

The other solutions by other posters will work and are simple enough to implement, but you might also consider a refactoring which involves moving the field to a non-MonoBehaviour class. (This of course depends on the rest of your design; it might also be a terrible idea).