We currently have validation for the TKey generic type parameter passed to the collection type, and we have validation for the key property type on the model (i.e. on the .NET type and VectorStoreRecordDefinition), but we don't validate that the two actually correspond. That is, somehow could construct e.g. a Qdrant collection with a VectorStoreRecordDefinition with key type Guid, but with a TKey of ulong. We can centralize this validation in the model builder as well, along with the rest.

Noet that Cosmos NoSQL is one partial exception. By default, the provider simply configures the document ID as the partition key; in this scenario the provider behaves just like any other provider (there's only one key). However, if the partition key is (explicitly) configured to be different than the document ID (or possibly multiple properties), then the TKey type parameter is a CosmosNoSqlKey, though the key property in the model is still just the document ID (e.g. a single string). There's already some validation in place for this - make sure everything is correct.