But what the componentIndex give us is which of the composite component is the cql3 column name. Typically, with collections, it's not even necessarily the last of the component. Now, if you know the table is a CQL3 one, you could try to infer which component it is by saying that it's the last component, except if the last is a collection type, in which case that's the previous one, but that feels a bit messy. And besides, thrift client libraries don't have a simple automatic way to know if the table is a CQL3 one in the first place. I guess you could say that if you have a composite comparator and some column_metadata then you are likely a CQL3 table, but again, not very clean imo.
At least internally I would be in favor of keeping the componentIndex as it is cleaner. I guess we could start returning the ColumnDefinition from CQL3 table without the componentIndex and let thrift client infer what they can. As said, I still think using CQL3 table from thrift has other way to be confusing, but why not.