Hello.
I agree with the suggestion above to support only the "new" way to describe variables. After all, the reason to introduce the "new" system was to deprecate the previous two competing styles, and then have only one going forward. The remaining "has part"-based variable explanations are mostly there because some editors kept reintroducing them. But eventually I think they'll go away - especially if there's support from the math extension maintainers.
I also share the hope that for the next five years at least there won't be any changes to the "new" system.

I confirm that https://www.wikidata.org/wiki/Q30204 is modeled correctly using the "new" scheme.

Modelling of Wikidata's data is typically discussed on Wikidata. Therefore I propose to close this task and continue the discussion there.
Regarding the alleged conflict of interest I'd like to state that I worked out the proposal for and participated in the migration to the property "symbol represents" in my free time, not as part of my job at Wolfram. The way formulas are modeled on Wikidata has no influence on any operations at Wolfram.

@Lydia_Pintscher: I tried to edit the value in the user interface, but had no success. Whenever adding the current value the invisible character re-appears; it does not appear when entering some other test value.

Thanks for fixing the script and clarifying the wording.

In case it helps: I had been able again to add math values for some time last week, but now it fails again.

I noticed this failing about one day ago.

The issue seems to be that the API expects the unit item to be of the form location + /entity/QID instead of concept base URI + QID, where location is the address on which the wikibase instance is accessible (say, the main page).
For Wikidata this is not an issue because users go to wikidata.org and edit there: location and concept base URI coincide (more or less).
However, in a production environment, edits might happen on a temporary URL before pushing the instance to the production URL. For both instances (temporary and production) the concept base URI is the same. Therefore, the unit item should start with the concept base URI.

Hello. I just ran into the same issue.

Hello. I stumbled over this ticket out of curiosity. Here my contribution:

This seems to have fixed itself. Probably this was related to the switch to the new label service.

Thanks for the explanation and welcome to the new team member.

By the looks of the lag it seems like the import has finished.
Running the query provided by @Dipsacus_fullonum a couple of times (with slight variations to "trick" the cache), the unit wd:P174728 is still present in the result of all runs.
Does that mean that wdqs1010 is not part of the pool for public queries, or that the invalid values made it into the dumps?

I changed my mind as mentioned on the talk page: Support for changing this property to external ID.

Just left a note on the property talk page (weakly) opposing this change. There I explain, why (to keep the discussion in one place).

Correct, thanks. (Still learning how to create good tickets.)

By the way, I had noticed this problem at least a year ago for the first time and stumbled over it now and then.

Firefox 68.0.1 on macOS 10.14.6.

The second time I press the Tab key the focus moves from the language search field to "Show globe", as indicated by the arrow:

I had tried the Tab key before, but I'm not able to select any language with it: Pressing it once complete "sp" to "Spanish", pressing it a second time focuses "Show globe", that is, leaving the language selector.
Using Firefox, if that's relevant.