Refactor: stop exposing indices when we only support one.

[myronmarston]

Originally, we thought we might support multiple but there's never been a need and it's annoying to always have to deal with indices as a list when we only have one (or none).

As part of this, we've changed the behavior slightly for when index is called more than once: previously, we replaced the existing definition. Now we raise an error as we should.

[zachbutler-squareup]

Is this going to make going back to a list (if that's ever needed) harder? I know we don't foresee that being a thing but also curious if this is potentially limiting in a future way that outweighs the benefits of the simplicity now.

[myronmarston]

Is this going to make going back to a list (if that's ever needed) harder? I know we don't foresee that being a thing but also curious if this is potentially limiting in a future way that outweighs the benefits of the simplicity now.

Great question. It may make it a bit harder but overall I think it'll be a wash. There will be more lines of code to change, but it'll be easier to identify what lines of code need changing (anywhere that accesses object_type.index_def is clearly assuming only one index definition, and needs to be updated). In contrast, right now there are places that use indices and therefore look "ready" for multiple indices but they do indices.first and they actually aren't ready (since they assume only one).

And with modern AI tooling I don't think it'll make much difference either way.

Finally, given how long we've gone without having a concrete need or use case for multiple indices, I don't think it's very likely that we'll have a use case for it that warrants that investment. It feels purely speculative ("just in case") to keep it around.