Null state when comparing unconstrained T to null

[RikkiGibson]

There are some slightly interesting nullable scenarios when it comes to comparing unconstrained/class?-constrained T to null. I opened an issue a while back to try and address what I thought was a bug (demonstrated below).

SharpLab

#nullable enable

public class C
{
    static T F1<T>(T t) where T : class?
    {
        if (t is null)
        {
            return null; // warning
        }

        if (t is null)
        {
            return t; // no warning
        }

        t = null; // W-warning
        return t; // warning
    }
}

Basically, our shipped behavior is that comparing a T to null does not "downgrade" the flow state to MaybeDefault. This seems to be because we don't have a test that "upgrades" a variable's state from MaybeDefault to MaybeNull, i.e. that tests that a variable contains a valid value for its declared type.

If we were to change this to resolve the strange behavior in the above sample, we would introduce potentially unpleasant behaviors other scenarios. For example, if you null-test some input to safely access members on it, we would suddenly start doubting that the input is a valid value of the input type, and we won't let you return it.

SharpLab

#nullable enable

public class C
{
    public string? Prop { get; set; }
}

public static class CExt
{
    public static T WithProp<T>(this T t, string? prop) where T : C?
    {
        if (t != null)
            t.Prop = prop;
        return t; // no warning currently, but would warn if we made a comparison of `T t` to `null` introduce MaybeDefault state
    }
}

After studying this scenario for a little while, it feels like something we should leave alone, but it's odd enough that I thought I would raise the question anyway. Should we change any behavior around this?