"Did you mean" part of DYM suggestion is GUI, I don't think we should put it in API response.
BC is a pain but still by default I am inclined to it. In this case it means that if we have suggestion, we should keep suggestion and if we rewrote query we should keep rewrittenquery. I am open to being convinced otherwise though. In any case we should ask people actually using the API (mobile team? others?) what they think.
I would really like to not have numbers in case all languages are different. I am aware this is a bit misleading and may be extra work in case they aren't, but that makes 99% of frequent cases much easier to handle. At the expense of breakage potential in 1% of other cases.
I am not sure how the rewrite scenario is supposed to work now. Previously, if original query returned no results, we'd use (if allowed) rewritten one and do rewrittenquery. Now what would original search return? Nothing? May not be helpful, especially as one doesn't know which additional result is the rewritten one before scanning all of them, and even then there may be more than one - so which one should be displayed? Too many options may be not helpful here. I think having a (configurable) preference order is better than just dumping everything on the user and having them try to sort it out.
That's reasonable. For the SERP page, is it okay for a module to give back UI text? Otherwise, Cirrus will have to know how to label the results of each module, and I thought we were trying to keep Cirrus from having to know anything about the modules. This applies to DYM and others.
I'm certainly not against that, though I left it out of the draft to see what people think. Asking API users is a good idea, and I want to ask the Mobile team, but we should get our first draft straight first.
If we go with multiple results sets in the API, getting two from the same language wiki might not be that uncommon. DYM and quote stripping would both give results from the original wiki. Also, If the numbers are consistently present, everyone will always parse them correctly. If they don't show up in 99% of cases, then when the 1% happens, things will break, as you noted. I'm not sure what to suggest. Always having arbitrary numbers is both easy to code and consistent for the consumer. What's so bad about the numbers?
One possibility is that rewrittenquery goes away in the main search results, and DYM is always a suggestion, even if the original query returns zero results. That allows the consumer to choose which suggestion to take (DYM, or one of the others). Alternatively, we could give DYM special legacy status and keep it exactly as it is and also put it in the additional search results section. That would require extra effort by new consumers to recognize that the main results are DYM results and not additional results, but it would be backward compatible for everyone else. Too many options is always a potential problem. I don't have strong feelings about a config for preferred order, but it seems reasonable, if it's easy for the consumer to convey to us.
