Implementing the same interface twice, indirectly and with nullability differences involving oblivious currently produces a warning, but arguably shouldn't:

#nullable enable

public class C : I<object>, IObjectOblivious // warning CS8645: 'I<object>' is already listed in the interface list on type 'C' with different nullability of reference types.
{
}

public interface I<T> { }

#nullable disable

public interface IObjectOblivious : I<object> { }

(sharplab)

On the other hand, implementing the same interface twice, directly and with nullability differences arguably should produce an error instead of just a warning:

#nullable enable
public class C : I<object>, I<object?> // warning CS8645: 'I<object?>' is already listed in the interface list on type 'C' with different nullability of reference types.
{
}

public interface I<T> { }

(sharplab)

Finally, this behavior is not consistently enforced on type constraints: direct scenarios (where T : I<object?>, I<object>) produce an error and indirect scenarios (where T : I<object?>, IObjectUnannotated) produce no diagnostic.

Relates to tuple name checks on interface implementations (issue #38427 tracks some irregularities).
Relates to PR #38460 (type inference can now handle types that implement duplicate interfaces with nullability differences).