ErikPilsits-RJW

The issue I'm pointing out doesn't have to do with the GetOrAdd factory. In fact, this library doesn't use that overload of GetOrAdd, so the Lazy implementation isn't even needed....

This is what I ended up with. It requires [Nito.AsyncEx.Coordination](https://www.nuget.org/packages/Nito.AsyncEx.Coordination/) for the async lock. ```csharp using Nito.AsyncEx; using System; using System.Collections.Generic; using System.Threading; using System.Threading.Tasks; namespace Common.Synchronization { public interface...

I don't think that will work. The idea of the lock is to be multi-threaded, so there will be different threads calling the same idToLock. That's why there is a...

Wanted to add my interest in this enhancement as well. Nice job!

I agree it should be implemented correctly in the NuGet package. There is no alternative for STJ here. Your case is a bit unique because you have a NuGet pkg...

But again, that's a fundamental misuse of a static settings instance, which is the correct way to use the settings. You can't keep re-adding an instance handler to a static...

It was not my intention to cause so much friction, rather to create the least breaking change which would accomplish the goal of fixing a serious issue with the generated...

I could have a template PR today for the above changes if desired.

We need feedback from @RicoSuter which approach he thinks is more appropriate, and how he feels about another breaking change. I think only your point 1 would be acceptable though....

@patrickklaeren This change would not be a revert, but would give the user more freedom to choose per instance or static options. Looking back at my suggestion however, I think...