Some of this has already been suggested or touched own by the team at the latest AMA webinar, and I thought it would be helpful to recap those there in addition to new ones.
- ability to pass coda objects to pack building blocks, namely being able to pass rows, tables, columns, pages, etc. directly as arguments for pack parameters. As already mentioned, on the technical side, passing these as copies of the data (at least directly) is probably infeasible, so a more realistic experience would be to receive references to these objects (probably urls, else some typed object with an id), which can be used to query the API for the data on demand. The use case is that there are already several such packs that make use of doc objects, but rely on more niche ways of bringing these into the doc, such as copying urls.
- ability to reference other tables as reference columns in pack sync tables. This would improve how sync tables that operate on coda objects integrate into docs.
I think altogether these features would enable higher level packs that instead of operating on data within doc elements, operate on doc elements themselves. I would see these as almost doc-builders or pre-baked automations to solve common and domain-specific patterns. Instead of just providing a table with an integration and requiring the user to glue it to their own data, to also be able to take in other tables of the doc as inputs and apply patterns and include them in the integration automatically.