Unconstrained generic T? suppresses nullable warnings without a clear caller contract

In C# 8 and later, an unconstrained generic type parameter annotated as T? produces a deferred nullability contract that the compiler cannot resolve until the type is substituted. The annotation carries different meanings depending on whether T becomes a reference type or a value type, yet the generic method body receives limited static guidance about which case applies.

Under where T : class, T? acts as a nullable reference type and default(T) is null; under where T : struct, it is equivalent to T and default(T) is the zero value. Because the compiler cannot determine the substitution for an unconstrained parameter, it often suppresses or downgrades nullable warnings inside the method, leaving callers responsible for handling both possibilities without static analysis support.

Library authors face a design choice between relying on T? alone and adding nullable attributes such as [MaybeNull] or [NotNullWhen] to communicate postconditions. The null-forgiving operator can silence individual warnings but does not change the underlying contract. Nullable analysis requires an enabled nullable context, and flow-analysis heuristics for generics have evolved across C# releases, so warning behavior may differ between SDK versions.

What contract strategy should an unconstrained T? return value use to support both reference and value type callers? Should nullable attributes be preferred over T? for mixed generic APIs, and how can authors confirm consistent compiler behavior across supported C# versions?