(ideally) provides an option to switch to the "basic HTML" version of the language switcher

I can see some benefits with the proposed approach, but I wonder if this makes more sense as a more general strategy (a basic HTML version for the whole app rather than for specific pieces). Do we expect all different controls (from search auto-completion to media viewing) that rely on Javascript to be showing the same kind of alternatives? That may be adding noise to the overall experience.

Javascript is an integral part of HTML. I think the no-JS makes not much more sense than supporting the non-CSS experience. I do agree that performance is important, and we should support slow internet connections. So I think it makes sense to make the language menu more performant first. The work on the new language menu (T253303) is a good opportunity for that.

There is a separate situation where someone has opened the language menu before javascript has started to load

For this scenario would be interesting to think if the no-js menu could look like the JS one and do the switch when the user clicks on the search bar. That would make the transition more seamless. Along those lines, one consideration for the new language menu is how to distribute the loading of Javascript. That is, would it make sense to load a minimal set of resources to guarantee that the menu renders first and keep loading more capabilities later to take advantage of the time between the user opening the menu and starting to type? (cc @santhosh)