In short this seems to fall into "maybe we can do better in the future" - though it seems that future has not yet come to fruition.
To my knowledge this dynamic isn't called out anywhere though it seems almost obvious once pointed out.
There still seems to be something off here:
> unfortunately it causes execution to use a snapshot that has been acquired before locking any of the tables mentioned in the query
I went down the path that the planner should be the one realizing that the view-using query has a lock it cannot grab - on the rewritten query's introduction of the new table - and it should have blocked in the planner, resulting in the acquisition of the execution-time snapshot in that case as well.
Apparently the planner gets to bypass a check (that blocks) that parse analysis has to perform. Thus locking of tables does happen for the ones named in the query text itself?
