Isn't it possible to modify the generic overload implementation to have the same behavior as the non-generic one?

The generic one is statically typed to return ILogger<T>:
https://learn.microsoft.com/en-us/dotnet/api/microsoft.extensions.logging.loggerfactoryextensions.createlogger?view=dotnet-plat-ext-7.0#microsoft-extensions-logging-loggerfactoryextensions-createlogger-1(microsoft-extensions-logging-iloggerfactory)

LoggerFactory.CreateLogger returns ILogger, and the instances it creates almost never implement ILogger<T>.

It seems very simple to modify the implementation of the generic version to delegate the creation of the logger to the factory as well.

Please share.

Sorry, I didn't see the return type is not the same. Can we not modify the implementation of the generic version to cache the logger (like the non-generic version)?

Technically, sure, it could have a thread-safe cache per T, indexed by ILogger and storing an ILogger<T> that wraps that ILogger, but it would also need to be throttled in some way, as if the underlying CreateLogger always produced a new instance, the cache could grow unbounded. That's not trivial to get right, in particular around cache eviction policies. The 95% use case for this method, as well, in situations where the extra allocation doesn't matter: you'll note that this PR didn't change the vast majority of uses of CreateLogger<T>, only ones where it's used in a manner where the caller itself isn't caching... most of the time, a caller stores the resulting instance into a field of something longer-lived.