.NET Core Dependency Injection giving "Ambiguous Constructor" errors after update to version 5.0.0

I have a number of classes that consume API services and whose constructors follow the pattern below:

public class SomeClass
{
    public SomeClass(IHttpClientFactory factory, ILogger<SomeClass> logger = null)
    {
        // ...
    }
        
    public SomeClass(HttpClient client, ILogger<SomeClass> logger = null)
    {
        // ...
    }
}

The first constructor is the one used by .NET Core's built-in dependency injection (by calling IServicesCollection.AddHttpClient() from the Startup.ConfigureServices() method, and then calling IHttpClientFactory.CreateClient() in the constructor); the second constructor is mostly used for unit testing, to allow a HttpClient (or mock) to be passed in. This has worked fine until now, but this morning I started getting errors like the one below:

An unhandled exception has occurred

System.InvalidOperationException: Unable to activate type 'Service'. The following constructors are ambiguous:Void .ctor(System.Net.Http.IHttpClientFactory, Microsoft.Extensions.Logging.ILogger`1[Service])Void .ctor(System.Net.Http.HttpClient, Microsoft.Extensions.Logging.ILogger`1[Service]) at Microsoft.Extensions.DependencyInjection.ServiceLookup.CallSiteFactory.CreateConstructorCallSite(ResultCache lifetime, Type serviceType, Type implementationType, CallSiteChain callSiteChain)

... long stack trace elided...

This was working up till now. It seems strange that the dependency injection mechanism considers the constructors to be ambiguous when IHttpClientFactory and HttpClient do not share any common interfaces.

I updated both Visual Studio 19 to the latest version (16.8.2) and all NuGet packages in the solution at the weekend. The Microsoft.Extensions.DependencyInjection package is now version 5.0.0; previously it was version 3.1.9. I have worked around the issue for now by removing the constructors that take the HttpClient argument and replaced the code in my tests to use a mock IHttpClientFactory instead, so the actual impact was low. However, it would be help my peace of mind, if nothing else, to understand why this broke in the first place. Is there some aspect of configuring .NET Core dependency injection that I have overlooked? Or has the strategy to resolve dependencies changed subtly between versions 3.1.9 and 5.0.0?