Regarding temporary resultsets I'm thinking of adding a #view command instead that creates an SQL view that is shared between invocations and doesn't accept parameter bindings.
The main reason why I want my own full SQL query parsing is because of the reactive views: I want to be able to show 1000 long tables and when a change to a row is made from outside, be able to react to the change without reading the whole 1000 long table again, just push that 1 line change with the websocket. This can be useful for chatbots/chats/live infinite scrolling where the content changes / new content comes in.
Still, it just constructs new SQL queries that are easy to optimize, like SELECT * from (SELECT * FROM T) where id=1 (SQLites optimizer is rewriting these queries quite fast, so I don't want to write my own optimizer, just query builder for reactive SQL).
In the future though I'm planning to add reactive query support where it is really advantagous to have low latency between the PageQL rendering engine and the database.
For MySQL/PostgreSQL for example an extension would run much faster, and give back the results, that's why I don't want to add async / http downloading / scripting support inside PageQL, just keep it simple to implement / embed.