question: Is it worth considering having more returns of SentryId ... potentially in a follow-up issue/PR?

• CaptureTransaction
• CaptureSession

I don't think so. Those methods aren't user facing (they're SDK user facing). This method is an exception in that there will be some UI around it in the app and so some feedback is required for the actual user (not just the SDK user).

Certainly nobody has ever asked for this...

thought: Nullable<T> vs non-nullable

I am a bit hesitant about a Nullable<enum>.
I'm thinking about having an additional 0 value in the enum, like None.
Or alternatively something like Done or Succeeded and calling the enum instead CaptureFeedbackStatus.
Similar to

• https://learn.microsoft.com/dotnet/api/system.buffers.operationstatus
• https://learn.microsoft.com/dotnet/api/system.threading.tasks.taskstatus

I do prefer the latter ... but personal preference ... I'm convincible 😉

I tried that but it means we have to do weird stuff like this in one of the constructors:

    public CaptureFeedbackResult(CaptureFeedbackResultStatus resultStatus)
    {
        if (resultStatus == CaptureFeedbackResultStatus.Success)
        {
            throw new ArgumentException("Use alternate constructor to indicate success.", nameof(resultStatus));
        }

        EventId = SentryId.Empty;
        ResultStatus = resultStatus;
    }

I think that's just as messy personally. I don't think the current design is any better or worse than the alternatives then.