Great initiative! One that I’ve been taking a look into myself, but bigger priorities came up 
.
These extensions remind me of dialects.
XCM does not have dialects (though it allows arbitrary execution via the Transact escape hatch) and the XCVM is not turing-complete. That is by design.
We want XCM as a way to standardize things we do in Polkadot, or in general in consensus systems.
I’d imagine XCQ to have the same goals in mind.
That said, I’d use a DSL for XCQ, with the runtime API entrypoint you mentioned. I don’t think we need the PolkaVM. Then, new queries can be added via an RFC process like the one for XCM.
Then, both XCQ and XCM should be managed by either an ecosystem collective or an XC collective, to make sure we all agree on the standards.
The main idea of how new features are added is that a subset of users in the ecosystem will experiment on a new subset (so as to differentiate it from dialect) of features using Transact and then create an RFC to make sure it benefits the whole ecosystem.
We can create something similar for XCQ, have an escape hatch (QueryRaw?) that they can use to experiment on a new query type. Then, when that’s widely used or they think it will benefit the whole ecosystem, they put up an RFC to include it in the standard.
I think also relevant to note is that not every chain has to support every possible XCM instruction/XCQ query, but senders can send anything to anyone.
I’d want to see a way of exposing which instructions/queries your chain supports.
There’s power in having a standard, wallets can know that if they support XCM/XCQ then they’ll be able to do the same operations/queries on each chain that implements them.
A common pain point in the ecosystem is that everyone does things differently, we should focus on standardizing more.
We are already flexible enough, if you want to expose something custom (an extension) you can always create a runtime API.