Thank you for submitting this for API review. This will be reviewed by @dotnet/aspnet-api-review at the next meeting of the ASP.NET Core API Review group. Please ensure you take a look at the API review process documentation and ensure that:

• The PR contains changes to the reference-assembly that describe the API change. Or, you have included a snippet of reference-assembly-style code that illustrates the API change.
• The PR describes the impact to users, both positive (useful new APIs) and negative (breaking changes).
• Someone is assigned to "champion" this change in the meeting, and they understand the impact and design of the change.

I like the alternative designs, because it's more reliable than checking the ItemCount after calling Return. With just ItemCount, I don't think it's possible to reliably determine how many items got disposed. I supposed you could implement a custom IPooledObjectPolicy that tracks the calls to Create and Return, but you could do this already. That doesn't mean we shouldn't make this easier though.

Unfortunately, we cannot make any breaking changes. We would need to add a new version of Return that returns a bool, and we'd need to come up with a name other than Return for this, since you cannot overload on return type in C#. Maybe "TryReturn" would be a good name for the bool-returning version of return even though Return is already best-effort.

Also, are you sure you're okay with not making changes to the ObjectPool abstract base class? It's a lot easier if we don't need to change the base class because we won't have to worry about the default virtual implementation or capability-testing. But if you're not using the abstraction, I'm not sure how much value ObjectPool really adds over managing the ConcurrentQueue yourself which would give you far more flexibility and introspection capabilities.