Doc comment might not be ideal. Though it will be hard to spot sealed override property with same name. In the context of method conflictingMember will be the first member with such key encountered (base class members come first). Which can be done with something like code below (though I'm not sure if it is a valid usecase).

public class A {
    [Key(0)]
    public virtual string Prop { get; set; }
}
public class B : A {
    [Key(1)]
    public sealed override string Prop { get; set; }
}
public class C : B {
    [Key(1)]
    public new string Prop { get; set; }
}

And I wonder if the right fix is to re-think how we do this because I don't understand why virtual or interfaces should even come into it at all

For virtual properties you want to have only one definition, because virtual method table will always give you latest implementation from a derivied type. If we re-think of design, one solution would be to force [IgnoreMember] on overrides within analyzer.

var b = new B() { Prop = "a" };
Console.WriteLine("=>" + (b as A).Prop); // Prints "=>a"

Speaking of interfaces, they are virtual because it is a CLR implementation detail. When you read method attributes using reflection, you get CLR attributes.
EDIT: In IL interfaces looks much like pure abstract classes and for performance reasons property methods are made final unless property is declared virtual itself (sharplab).

Also there are problems detecting new keyword using reflection. I don't see any difference in MethodAttributes for the following case:

public class A {
    public string Prop1 { get; set; }
    public virtual string Prop2 { get; set; }
}
public class B : A {
    public new string Prop1 { get; set; }
    public new virtual string Prop2 { get; set; }
}

Also there are problems detecting new keyword using reflection. I don't see any difference in MethodAttributes for the following case:

I believe Reflection can distinguish between the two cases, if you know what to look for. It probably isn't in MethodAttributes as you say.

But these are extremely narrow cases and it sounds like your PR improves a more common case.
I'll push a fix for the build break and merge.

Ah, can you also please apply your proposed comment change? That's good.

Updated comment. Didn't want to change it twice.

As for the new keyword it is a very narrow case and not goal of this PR.