I love elevating this concept so that any service can use it. I have a few ideas and thoughts that you can take or leave:

1. Consider whether Data or something else is a better name. To me, the words Result and Response are bit too close semantically and are pretty much interchangeable.
2. Is it possible to add a T : class constraint?
3. It might be helpful to add HasData and/or TryGetData(...) APIs. If T is constrained to class, declare Data as T? and then add [MemberNotNullWhen(true, Data)] to HasData and [NotNullWhen(true)] to TryGetData.
4. StopHandling feels a little awkward to "handle" on the client side. I wonder if there's a better name or combination of signals. In general, it feels strange that the remote service would have so much knowledge about what the client does with the response. It also feels a bit odd to me that a RemoteResponse might have a Result and StopHandling == false. I don't have any great suggestions, so please don't make any changes related to this unless you have better ideas. However, I suggest that we keep thinking on this logic.

This type is the epitomy of "naming is hard". Trying to work out names for the parameters, and the helper properties, that didn't clash and meant something etc. I do not disagree with any of your feedback.

I'd like to re-use part of this PR in the inlay hint work I'm currently doing though, so if you don't mind I think I'll merge this as is, but will do another pass on this class specifically in a separate PR. I think making it not a record might be the key, so we can separate out consructor params, properties etc. and allow some more nuance in these.

I will say for your item number 2, at the moment no, the first use of this was with Roslyn's TextChange which is a struct. It certainly would have made the nullability bits easier though :)

I have no problem with merging this as is. I just wanted to write my thoughts down. We can definitely get back to them later as we go.