Description

XmlSerializer does not really distinguish between hidden (aka 'new') and overridden members.
There was a couple of PR's some time ago that nominally addressed some 'override' issues where
the access modifiers were more restrictive from the base (#22560 fixed by corefx/#21719, and
#22569 fixed by corefx/#21913) but the issue here is that those are hidden scenarios.
Overrides don't change access modifiers.

In reality, the serializer just doesn't handle hidden members very well.
Take these two classes for example.

public class A {
    public virtual string Hidden { get; set; }
    public virtual string Modified { get; set; }
    public virtual string Ignored { get; set; }
}
public class B : A {
    private string hidden, modified, ignored;
    public new string Hidden { get { return hidden; } set { hidden = value + " from B" } }
    internal new string Modified { get { return modified; } set { modified= value + " from B" } }
    [XmlIgnore]
    public new string Ignored { get { return ignored; } set { ignored= value + " from B" } }
}

If you create an instance of B {Hidden = "h", Modified = "m", Ignored = "i", A.Hidden = "hidden base", A.Ignored = "base ignore" }, then A.Hidden gets lost in the round trip, and A.Ignored goes on the xml "wire" but actually gets restored on B.Ignored
despite the property having the ignore attribute. Things are also goofy if you try serializing or deserializing as type A, which you should be able to do without losing or confusing data.

Bottom line is that we don't handle hidden properties well. Trying to put hidden properties on the "wire" would require convoluted namespace considerations beyond what already exists in order to keep things straight.

I think a prudent way to go would be to detect "hidden" scenarios and raise an error since we don't handle these in any
consistent way.