note: A NestedProperty is necessarily different to a Property since you can't set inverted indices nor tokenization on a nested property. Perhaps you're aiming defensively here in case that changes?

I haven't thought about that before to be honest. Planning for future change is a reasonable objective (I can imagine how we might allow building some inverted inverted index on the object property in the future), but my main intention here was simplicity.

you can't set inverted indices nor tokenization on a nested property

I'd argue that a separate NestedProperty type will over-specify the API. Consider: IndexRangeFilters is only applicable to int, number, and date property types, and Tokenization cannot be set for anything other than text and text[] properties. Still, we do not provide distinct ArithmeticProperty, TextProperty and BlobProperty in the spirit of keeping things simple and, as you've suggested, flexible.

I'd argue that a separate NestedProperty type will over-specify the API

We are currently planning filtering+search support for NestedProperty and there is a good chance that some config values will be different than normal Properties. I think for this case it makes sense to have an extra type

config values will be different than normal Properties

Do you mean like Tokenization field would exist but would accept a different value? E.g. it's string for text/text[] properties but []bool for object/object[]? If that's the case, then I agree that this warrants a separate type.

I don't think it is necessary otherwise. If we take a close look a the current property config options, most of the properties aren't "normal".

// Applicable to all property types without exception
Name              string
Description       string
DataType          DataType

// Exclusive to `object` and `object[]`
NestedProperties  []Property

// Exclusive to `text` and `text[]`
Tokenization      Tokenization
IndexSearchable   bool

// Exclusive to `int`, `number`, and `date`
IndexRangeFilters bool

// Not applicable to `blob`, `object`, `geoCoordinates`, `phoneNumber`
IndexFilterable   bool

Only 4/8 configurations are applicable to "most" property types.

It also makes the API less consistent. Consider an object property address { street, building_nr }:

NestedProperties: []Property{ 
  {Name: "street", DataType: "text", IndexSearchable; true}, // Invalid -- NestedProperty would fix that
  {Name: "building_nr", DataType: "int"},
}

The issue with using Property directly is I can specify IndexSearchable which is a mistake -- the NestedProperty simply wouldn't expose that config. What if in the future we decide to make nested text searchable but not text[]? We'll extend NestedProperty with a new field and end up where we started, i.e. the user can accidentally send an invalid request.

NestedProperties: []NestedProperty{
   {Name: "one": DataType: "text", IndexSearchable: true}, // OK
   {Name: "many": DataType: "text[]", IndexSearchable: true}, // Invalid
},

Do you mean like Tokenization field would exist but would accept a different value? E.g. it's string for text/text[] properties but []bool for object/object[]? If that's the case, then I agree that this warrants a separate type.

We are still in the planning phase so I cant tell you exactly what we have, but we might end up with different options for IndexRangeable than normal Properties. As we are quite far away from GA I am also ok with leaving it as normal Property for now with the option of changing it in the future (I haven't read the complete thread)

Something to note as well is that Property and NestedProperty are different types in the OpenAPI schema too so removing that point of difference in the client would be a conscious choice to differ from the server (not necessarily a bad thing, just pointing out)