Your configuration looks correct to me. I configured a similar setup using the OpenAPI example with the following changes:

Added:

[ApiVersion(1.0)]
[Route( "api/[controller]" )]
public class ValuesController : ControllerBase
{
    [HttpGet]
    public IActionResult Get() => Ok();
}

Changed:

[ApiVersion( 1.0 )]
[ApiVersion( 0.9, Deprecated = true )]
[ApiExplorerSettings( GroupName = "Orders" )]
[Route( "api/[controller]" )]
public class OrdersController : ControllerBase
{
    // omitted for brevity
}

[ApiVersion( 1.0 )]
[ApiVersion( 0.9, Deprecated = true )]
[ApiExplorerSettings( GroupName = "People" )]
[Route( "api/v{version:apiVersion}/[controller]" )]
public class PeopleController : ControllerBase
{
    // omitted for brevity
}

.AddApiExplorer(
    options =>
    {
        options.GroupNameFormat = "'v'VVV";
        options.SubstituteApiVersionInUrl = true;
        options.FormatGroupName = ( group, version ) => $"{group}-{version}";
    } );

which produces the following:

• ORDERS-V1 only contains the 1.0 version of the OrdersController
• PEOPLE-V1 only contains the 1.0 version of the PeopleController
• V1 only contains the 1.0 version of the ValuesController

Everything else is unchanged. That is what I would expect.

I see that you're still using the older Startup.cs approach, but I don't think it should matter in this case. You will have gone through the full DI cycle at this point and IApiVersionDescriptionProvider should produce the correct results. Are you sure there are any APIs in v1? In theory, it shouldn't be possible for that to happen. I may need a little more context or the world's simplest repro will help. Perhaps the repro steps I used will be helpful to you.

Sidebar

ApiVersioningOptions.AssumeDefaultVersionWhenUnspecified = true will not what you think it will unless you have more configuration that I'm not seeing. This is a highly abused feature that is only meant for backward compatibility. When you chose to version by URL segment, it virtually has no effect. The only way it can work is if you use Double Route Registration (ex: api/v{ver:apiVersion}/accounts and api/accounts). In this case, there is no API version derived from the URL so it will be assumed since it has been configured as allowable. The only other exception would be if you have mixed styles and are moving away from versioning by URL segment (🤞🏽). I'd recommend explicit versions should that be the case. This is the same problem as order/{id}/items. There is no way to assume or otherwise route to that path without {id}. The ASP.NET routing system doesn't support that.