Yep, this indeed (slightly) diverges the API for framework/netstandard2.0 vs. net8.0 - and it's slightly less nice for provider implementors. But as much as possible, I think it's important to not compromise the developer experience of modern .NET users just because we also support old .NET users... We don't currently have much provider-specific APIs, but this is something I expect will change in the future, and at that point users of e.g. Azure AI Search should be able to access such APIs without ugly downcasts. Projects that need to still support old .NET can simply not depend on this feature, and write code that expects VectorStoreCollection rather than AzureAISearchCollection - that'll compile and work everywhere.

BTW the designers of System.Data also placed a lot of importance on the single-provider users getting the provider-specific types rather than the abstraction types. Since covariant return types didn't exist back then, they implemented the following pattern:

class DbCommand
{
    // Non-virtual public method. This gets hidden 
    public DbDataReader ExecuteReader() => ExecuteDbDataReader();

    // Virtual protected 
    protected abstract DbDataReader ExecuteDbDataReader();
}

class NpgsqlCommand
{
    // Hide the base non-virtual ExecuteReader. So if a user has an NpgsqlCommand, calling ExecuteReader()
    // on it returns an NpgsqlDataReader (great). But if the user has a DbCommand, calling ExecuteReader()
    // binds to the base method, and returns a DbDataReader. That's a sort of implementation of covariant types.
    public new NpgsqlDataReader ExecuteReader() => ...;

    protected override DbDataReader ExecuteDbDataReader() => ...;
}

We could implement this pattern instead of using .NET covariant return types, but it's a bit convoluted; I'm also not too concerned with optimizing the experience for .NET Framework users (they're already excluded from many good new stuff) - I'm mainly thinking about making sure modern .NET users get the best experience they can.