for the record the script to run was:
mwscript extensions/CirrusSearch/maintenance/metastore.php --wiki anywiki --upgrade

As pointed out by Erik the number of incoming links can sometimes overweight language preferences (this is especially true when using special keywords as they change the scoring formula). I have some hope that can unify the scoring behaviors with and without keywords in the query.
Without any keywords in the query I can see language preference in effect:

So for now we don't really distinguish between the initial namespaces and the namespaces found in the query.
In the current wikibase situation we fallback to cirrus builder anyways in the presence of keywords so this won't be an issue short term.

Initially I wanted to change how prefix works by disallowing any changes to the original list of namespace requested from the URL. Sadly this caused many components to fail and I had to revert. I completely agree with you that this behavior makes it difficult for us to make some decisions based on the list of namespaces.
Fixing the root cause by changing the behavior of the prefix: keyword seems hard to achieve in a reasonable amount of time. I'm not saying that it's impossible.

Does it mean that we would make WikbaseClient dependent on CirrusSearch and create all necessary query builders into this client?
Have we considered the possibility to run an actual API call to wbsearchentities@wikidata.org?
I have no clue if the current API output would allow to rebuild TermSearchResult nor if there are perf considerations that make this solution impossible.

I started to investigate but yes the 20s shard timeout is not reached before the curl request timeout.
Looking at the stacktrace I failed to see one using the source_regex staying around for long...
Asking elastic to return 0 results (to disable the fetch phase) the time spent is reasonable (20-30sec) and the timeout is properly triggered:

In proposal 2 does it mean we get rid of wgCirrusSearchWriteClusters?
On one hand I like the simplicity of the first proposal but I'd go with something like:

[ NS_FILE => [
   'read_cluster' => 'logical_name_used_by_crosscluster_search' # OR '__local__' if mw-config detects this wiki belongs to the same cluster
   'write_clusters' => [
         'eqiad-large-01',
         'codfw-large-01',
   ],
   'index_name' => 'commonswiki_file'
];

Few questions:

• if an image depicts (https://www.wikidata.org/wiki/Q830375) should we find it when searching images that dipict a car?
• if an image depicts 2 x https://www.wikidata.org/wiki/Q37629 and 3 x https://www.wikidata.org/wiki/Q37624 should we consider this as depicting 5 dogs?

@Legoktm no I don't think so, it happens only on patches I cherry pick to this branch. See https://gerrit.wikimedia.org/r/#/c/432984/ a test patch cherry picked from master (succesfull build on the master branch: https://gerrit.wikimedia.org/r/#/c/432981/).

Is it possible that the regression mentioned here is the cause of T194655?

I'm not sure this task is related to T194475. I'd look into the work being done around T193927.

Patch deployed, prefix and associated InputBox forms should work as before.

@Iniquity sorry about that, the change will be reverted soon, I underestimated the impact of the change and thought that the warning message was sufficient, this was a mistake.