IMO the best solution here would be to add triples of the form

sdc:M1234567  ?relation  <http://commons.wikimedia.org/wiki/Special:FilePath/Name.jpg>

to the database, as well as (or instead of??) the present

sdc:M1234567  schema:contentUrl  <https://upload.wikimedia.org/wikipedia/commons/5/5b/Name.jpg>

The URLs of the first form correspond to the form of the values of Wikidata properties like "image" (P18) and the rest, and are what the ImageGrid view looks for to find images in the output.

So adding triples of the first form would immediately solve the ImageGrid problem.

It would also solve a second issue, viz. that at the moment it is not possible in a query to take the values from wikidata properties like "image" (P18) and the rest, and add their Commons info from WCQS, because it is not easily possible at present to relate the URLs of the first form to the M-IDs M1234567 which are required to connect them to their Commons info.

Similarly, if one has generated a list of M-IDs in WCQS, one has to do a workaround at the moment to generate URLs of the first form, if one wants to identify which out of those M-IDs might be the value-objects of wikidata statements

Including triples of the form suggested, for some suitable predicate ?relation, should not be a difficult patch to apply, and would solve both of these issues, as well as allowing ImageGrid view to work straight out of the box.

See https://tinyurl.com/y26mtate for an example of how this is currently done. Given that items returned will virtually always be images (or at least things that can be represented as images) i guess it makes sense that every query always returns images and maybe uses the ImageGrid view as the default as well.

Isn’t this a duplicate of T258608: Image results on WCQS should be available?

Note: in an attempt to unblock the status quo I created T277665 with some practical solution (esp the first one suggested in T258769#6332430)