@dotnet-policy-service agree

@davmason, Hey! May I ask you too look at this?

Added other people from dotnet-diag for review

@davmason - did you want to take another look?
@eterekhin - I assume you are ready for this to merge if @davmason is also happy with it?

Thanks a lot for helping with this fix, folks!
@davmason, @noahfalk Could you please merge it? I guess the "Merge" button is hidden for me

@noahfalk do we need a breaking change doc for this? if so, please file it through https://github.com/dotnet/docs/issues/new?assignees=gewarren&labels=breaking-change%2CPri1%2Cdoc-idea&projects=&template=02-breaking-change.yml&title=%5BBreaking+change%5D%3A+ and mark this PR with breaking change label?

Would we typically write breaking change docs when we change an implementation choice that wasn't part of the original contract? I don't think of this as a breaking change in the formal sense but its true that some people may have taken dependencies on the threading behavior anyways.

We usually document any change that can cause breaking to the user. If this change is possible to break any behavior, I suggest documenting it, but it is your call if you think otherwise.

Cool, I'll file it.

/backport to release/8.0

Started backporting to release/8.0: https://github.com/dotnet/runtime/actions/runs/11224036440

/backport to release/8.0-staging

Started backporting to release/8.0-staging: https://github.com/dotnet/runtime/actions/runs/11224091393