Rolf Kristensen

> As far as I remember this is because of performance reasons Yes in the old days in NLog 1.1 there was nothing called generics. So to avoid the params-array-allocation,...

Think the only performance issue I can see is that ILogger interface causes all methods to be virtual. Would be a good idea if ILogger only contained the params-array method....

> no breaking changes, easy to mock. There is already a slimmer interface. Ok. I was just curious about the issue mentioned in #375, that implementing an interface would cause...

But still curious about what performance issue you see that might come from removing ILogger-V1.cs ?

> is less expensive with `log(int)` compared to `log(T t)` Less expensive at compile-time? not sure I understand.

Created PullRequest #4044 where `ILogger` is made obsolete to redirect users to a more simple `ILog`-interface.

Should be resolved with the following issues: #2582 - Move WCF targets to NLog.WCF package #2676 - Move DatabaseTarget to NLog.DatabaseTarget package #2680 - Move NetworkTarget to NLog.NetworkTarget package #2786...

Should probably consider moving even more targets out of the NLog-core-package if wanting to support platforms like Blazor (Extract File-Target + Trace-Target + Debug-Target + Console-Target etc. into their own...

Now implemented small work-around for FileTarget that ensures flushing will perform writing in batches. See also #3857

Could consider keeping IRawValue internal, and just reveal `Layout.TryGetRawValue()` since it is the only one needed for targets like DatabaseTarget.