Goals

• Make simple collation explicit in durable catalog index specifications.
• Ensure index specs returned from the catalog always include a collation field, even when the collation is simple.

• Remove the workarounds introduced in SERVER-89953 and SERVER-89744.

Why is this important?

When the durable catalog does not return an explicit collation for an index, subtle bugs arise for collections whose default collation is non-simple and that also have indexes explicitly created with a simple collation.

Key facts:

• An index created without specifying a collation inherits the collection's default collation.

• An index created with an explicit simple collation ({locale: "simple"}) must not inherit the collection's default collation.

• However, because the durable catalog omits the {locale: "simple"} collation, the index appears as if it has no explicit collation at all.

This leads to incorrect behavior in workflows that recreate indexes from reading the durable catalog, e.g. when cloning a collection:

1. The original collection has a non-simple default collation.
2. An index is explicitly created with {locale: "simple"}
3. The durable catalog returns that index without a collation field.
4. When the collection is cloned and indexes are recreated using the durable catalog, the recreated index is built without an explicit collation and therefore incorrectly inherits the collection's non-simple collation.

As a result, the cloned index does not match the original index's semantics.

Historic events

• SERVER-89953 introduced a targeted workaround to patch listIndexes behavior. However, this approach remains error-prone: future refactors or new features might add new code paths that recreate indexes directly from catalog or in-memory metadata without going through the patched logic from SERVER-89953, reintroducing incorrect collation semantics.
• SERVER-89744 introduced another targeted workaround to patch the collection cloning on resharding.