So SolidJS has this solved elegantly? It lets you choose between object identity and index, and it doesn't have that caveat for object identity because it knows what's going into <For> and not just what's coming out of it.

Don't omit the key in React unless you want warnings.

I know, I've read it. I'm still not convinced. React could just as well generate and insert missing key on build instead of asking me to do this:

... you can add a new ID property to your model or hash some parts of the content to generate a key.

It is just plain wrong to ask me to change my data model because of this. This is part of the housekeeping that I expect the framework -- pardon, library -- to take care of for me.

It can't. Not in a consistent manner. When diffing user provided immutable data you need a user provided key. Otherwise it can't tell the difference between a new list entry and a nested update. You could treat every nested update as a new item but that is incredibly wasteful as it throws away all descendants. This is something all non-fine-grained rendering libraries have to deal with be it React, Vue, Svelte, or Lit.

How does Solid avoid the need for user-provided keys? I thought it also had to diff the underlying array. Does it check object identity?

It does. Just referential check. Our reactivity is nested and we don't want blow out everything so even though there is read/write segregation and immutable interfaces the internals are mutable. In so sorting looks at referential equality, and nested updates don't even trigger list diffing.

Now this does require special process for intaking immutable or big data snapshots where we can't do reference comparison. So we do have a data diffing capability in our nested reactive stores to propagate only what changes. But for the most part common actions like partial updates highly optimized. As well as simple list operations like sorting.