I have seen a lot of discussion around the missing feature of (cascading filters, mutiselect dropdowns, etc). As a business intelligence guy, I have a design suggestion: implement a dimension editor in Data Sources that can edit hierarchical filter metadata on any Airtable table. It would allow you to specify a snowflaked logical schema around a ‘fact table’ in data warehousing terms.
The editor would let you specify different ‘link instances’ of a given table for each dimension hierarchy. For example, a Date table might be used as a ‘Start date’ in one link and ‘End date’ in another, for a given list record. The dimension editor lets you specify multiple logical copies of the Date table for each way it is used in your filtering schema.
With this additional hierarchy metadata, I believe that calculating the current combination of filter values selected is relatively inexpensive, because you don’t have to hit the big transaction table. You just filter the smaller dimension records. This does not get to the ideal state of calculating all the intersections across the big transactional table, but to do that you would have to slurp the whole Airtable into an in-memory cube or somesuch, which is technically infeasible. This snowflake dimension editor approach gets you 90% of the way there, and gets designers the desired cascading filter feature with good performance.
It adds a bit of configuration complexity to data source setup, but once you do it for a table you can reuse it in any list block the table is used in across any application. From a market perspective, you go a long ways towards providing missing Airtable analytics capability.