It doesn't really matter other than for consistency with other use, but whereas for a generic T we'll use [MaybeNullWhen(false)] out T, for a non-generic we'll use [NotNullWhen(true)] out string? .

I went with this since its what the interface declaration was.

Is there a preference on updating to NotNullWhen(true) instead or is there any conflict in doing that given the usage via generics?

Is there a preference on updating to NotNullWhen(true) instead

From a functionality perspective, it doesn't matter: [MaybeNullWhen(false)] out string and [NotNullWhen(true)] out string? are identical. We prefer the latter form in general because it more closely aligns with syntax of the language: the out is in fact nullable, hence the ?, and it's just that in certain circumstances we can use attributes to provide more information to the flow analysis, that we know even though it's nullable it won't be when the method returns true.

We can't, however, use [NotNullWhen(true)] out T, because the consumer might instantiate with a nullable T such that null is a valid value in the domain, such that NotNullWhen(true) would potentially be a lie. Hence, even though we prefer [NotNullWhen(true)], we use [MaybeNullWhen(false)] with unconstrained generics, since it ends up functionally being the same and is correct.

So, we do have a preference for [NotNullWhen(true)] when it's possible to use it. In this particular case, it's even less impactful because we're explicitly implementing the interface, so effectively no consumer will see the annotations here (outside of via reflection, which is really remote).