The two main types exposed by MEVD - IVectorStore and IVectorStoreRecordCollection - are interfaces; we will probably be changing these to abstract base classes. Some context:

• We'd like to be able to add methods with default implementations without breaking implementations; we don't want to end up in a place like System.Data, which was originally interface-based (IDbConnection, IDbCommand) and right afterwards introduced abstract base classes instead (DbConnection, DbCommand).
  • One concrete example is a new API for instantiating a collection in a NativeAOT/trimming-safe way. This involves accepting source-generated artifacts, but we don't yet know the precise shape. An abstract base class would allow us to add this later once a full design is clear.
• We also have some (minor) opportunities for default implementations, e.g. CreateCollectionIfExists could be implemented over an existence check and a creation.
• The original MEVD design was based around interfaces since some connector implementations implemented the interface multiple times. For example, QdrantVectorStoreRecordCollection implemented IVectorStoreRecordCollection twice, once for Guid keys and once for ulong keys. We since switched to a different approach, where QdrantVectorStoreRecordCollection itself is generic over the key, and an invalid key causes a runtime error instead. This was done for dynamic support (object key), but also improved the dev experience since the multiple interfaces required one of them to be an explicit interface implementation.