Hiding fails when there is a nullability difference.

[sjb-sjb]

Consider this, in C#9 with .NET 5

public class NonemptyPropertyChangedEventArgs: PropertyChangedEventArgs
{
    public NonemptyPropertyChangedEventArgs(string propertyName) : base(propertyName) 
    {
        Debug.Assert(this.PropertyName == base.PropertyName);
    }
    new string PropertyName => base.PropertyName ?? throw new NullabilityLogicException();
}

... 
var x = (new NonemptyPropertyChangedEventArgs("")).PropertyName;
...

Expected: x of type string, not inferred as nullable, and PropertyName is the new PropertyName property in NonemptyPropertyChangedEventArgs.

Actual: x of type string?, i.e. inferred as nullable, and PropertyName is the base.PropertyName property which is string? in PropertyChangedEventArgs.

[huoyaoyuan]

This is by design of var.

Examine this code:

var x = new XXX();
x = null;

To keep compatibility in this scenario, var is always inferred as nullable. The nullability of RHS is represented by nullable flow state of the variable.

[sjb-sjb]

Although var has the type of inferencing you describe, that is not the problem in this case. The expression on the right is inferred as nullable and a warning/error occurs if you try to assign it to a variable that is explicitly string rather than var. Hovering shows the base signature, and if you right-click and Go To Definition then it takes you to the definition of base.PropertyName instead of the new PropertyName in the derived class. Which seems completely wrong.

[CyrusNajmabadi]

The expression on the right is inferred as nullable and a warning/error occurs if you try to assign it to a variable that is explicitly string rather than var

That's not the case. You only get the warning of the compiler thinks that the variable might actually currently contain a null value. If it does not think the value could be null, you get no warning

[canton7]

Note that your PropertyName doesn't have an access modifier, which makes it private.

If you make it public, then the nullability seems to work fine. This doesn't throw a warning:

public class C
{
    public void M(NonemptyPropertyChangedEventArgs e)
    {
        Console.WriteLine(e.PropertyName.Length);
    }
}

public class NonemptyPropertyChangedEventArgs : PropertyChangedEventArgs
{
    public NonemptyPropertyChangedEventArgs(string propertyName) : base(propertyName) 
    {
    }
    public new string PropertyName => base.PropertyName ?? throw new Exception();
}

Dotnetfiddle (I'm not using SharpLab, as it doesn't seem to be referencing .NET 5, which is where PropertyChangedEventArgs is properly annotated).

Whereas if you comment out public new string ..., you do get a warning.

This also explains why Go To Definition didn't appear to work -- you were actually referencing PropertyChangedEventArgs.PropertyName, since the compiler was unable to bind to NonemptyPropertyChangedEventArgs.PropertyName, as it's private. @huoyaoyuan explained why the var s = e.PropertyName infers s as a nullable string? (although with a not-null flow state).

[sjb-sjb]

Wow, glad I was wrong on that one! Thanks!