This looks pretty similar to what we have found as a cause of RevisionSlider tests failures started around last weekend (T153121). We've managed to track the issue down to https://gerrit.wikimedia.org/r/#/c/324387/.

mw.language.convertNumber test added there is changing separatorTransformTable to an arbitrary value, and does not re-set it after the test, which causes the setting to be applied to tests run after that one. This affects the way numbers are printed, as seen in this case too.

What we've done regarding T153121 was setting separatorTransformTable to null at the beginning of number-printing-senstive tests, so all changes from mw.language.convertNumber test do not affect "our" tests. We also remember the original value before "our" test and restore it after it is finished, just in case further tests relied on this specific value of separatorTransformTable (this does not seem to be a case, though, but I only had a very brief look).

Setting that field to null would probably be a quick solution. But the question that also came to my mind yesterday was is it actually intended mw.language qunit test change some settings but do not "clean up" after themselves? This separatorTransformTable issue is only related to a single test but for example wgUserLanguage is being changed multiple times in these teste. Can we be sure those settings do not affect other tests? Especially what I was thinking was maybe their order guarantees that language/locale setting do not affect stability of core qunit tests suites but could we be that sure about this when it comes to extensions?

There are arguments for both ways: tests should define their dependencies and avoid global state; tests should clean up after themselves (if the framework does not do it).

Resetting default values seems simple and sane there.

It does reset them though: the teardown callback resets mw.language.data.values to what was saved in the setup. As far as I can see this includes separatorTransformTable. The problem is that for some reason it nondeterministically fails to have any effect.

The mw.language test cleanup uses mw.Map.values which has been deprecated

Actually, it doesn't. mw.language.data is not a mw.Map instance and the setup/teardown code in mediawiki.language.test.js effectively does nothing - other than storing the undefined value, creating an unexpected values data property (as language code) and setting it to an empty object.

QUnit.module( 'mediawiki.language', QUnit.newMwEnvironment( {
  setup: function () {
    this.liveLangData = mw.language.data.values;
    mw.language.data.values = $.extend( true, {}, this.liveLangData );
  },
  teardown: function () {
     mw.language.data.values = this.liveLangData;

	/** ..
	 * @class
	 * @singleton
	 */
	mw.language = {
		/** ..
		 * @property
		 */
		data: {},

Fixed in https://gerrit.wikimedia.org/r/327881 - though I suspect it may be unrelated to this task's bug.