Additional user feedback:
(1) Take the 80/20 approach and focus on the single-table use case for starters; don't get hung up on the complicated join/union cases.
(2) Propagating metadata about the partitioning key through to the view will be important in UI's which auto-suggest a filter on the partitioning columns. A nuance here is that if the filter is baked into the view definition itself (i.e. the view is partition-specific), then we might not want to propagate it (if the view creator forgot to project it away).
(3) It would be nice if a system function CURRENT_PARTITION() were provided so that the view definition could bake in a dynamic filter like WHERE ds=CURRENT_PARTITION(). This is an independent but related feature whose semantics remain to be worked out.