Case A: we're unnesting a list col that was a key: not sure if this is even something we'd run into
Case B: we're unnesting a list col that wasn't a key. We're probably expanding the row set. To get a unique key, some of the columns from unnesting should be included in other_keys. We need help in identifying these, either from a special class or directly from user.
Case C: we're unnesting a tibble-type / vctrs generalization but not list column that was a key: probably we should replace the original column with all new columns as keys, but this isn't 100% guaranteed. We might need some help from the unnested object to point to what new columns should be considered keys.
Case D: like Case C but for a non-key. Assuming this can't expand the rowset, then we don't need any other_keys updates.
Case A: we're unnesting a list col that was a key: not sure if this is even something we'd run into
Case B: we're unnesting a list col that wasn't a key. We're probably expanding the row set. To get a unique key, some of the columns from unnesting should be included in other_keys. We need help in identifying these, either from a special class or directly from user.
Case C: we're unnesting a tibble-type / vctrs generalization but not list column that was a key: probably we should replace the original column with all new columns as keys, but this isn't 100% guaranteed. We might need some help from the unnested object to point to what new columns should be considered keys.
Case D: like Case C but for a non-key. Assuming this can't expand the rowset, then we don't need any
other_keys
updates.