moving back to in progress as we'd prefer to keep HHVM connection pooling while still running HHVM but prepare mw-config so that it uses the local proxy when PHP is detected.

Copying Krinkle comment here:

This seems very similar to T215713 (probably duplicate).

looks like it was already done in https://gerrit.wikimedia.org/r/c/integration/config/+/489800 but sadly this does not seem to be effective, CI is not triggered, see test patch: https://gerrit.wikimedia.org/r/c/search/glent/+/491658

Once ES6 is running we should just make sure to disable LTR just before we reindex the korean wikipedia. The migration itself should not affect anything related to LTR.

Sounds good to me and easy enough to test

In general ORing a keyword is only meaningful for keywords that match a code, it's rare when people ask us why thay can't do intitle:foo OR intitle:bar. But here since we have multiple languages I feel that one may ask for a word in two different languages and prefer having a OR between the two. I think you are right that we should not push too much on the first iteration.
We are not that far from supporting OR between keywords, that parser is ready we just need to write the query building code. We are perhaps close enough that it preferable to stick with the simple syntax.

Why not put the languages as a suffix?

Thanks for catching this, here is an updated version of the deb package which should fix the issues you discovered:
https://people.wikimedia.org/~dcausse/wmf-elasticsearch-search-plugins_6.5.4-alpha6~stretch_all.deb

According to https://en.wikipedia.org/w/api.php?action=query&format=json&prop=cirrusbuilddoc%7Ccirrusdoc&titles=Wikipedia%3AVillage_pump_(technical)%2FArchive_9&formatversion=2 the create_timestamp field is not yet present in the index. I suspect our reindex process to have missed this page since I believe we waited for 2 month before announcing that this new field was available (2 month being the time we estimate a full refresh to take).
We'll have to investigate the logs to determine what happened but since it's a 2 month process clues may be hard to find.

Thanks @Joe! I'll follow-up on this and prepare mw-config patches to use these new entries.

a test package with the korean analyzer is available here: https://people.wikimedia.org/~dcausse/wmf-elasticsearch-search-plugins_6.5.4-alpha2~stretch_all.deb