Tuples and unions have invalid names, but are the restrictions on names really justified?

Per the explainer, words can only contain the ASCII letters and numbers, and must start with a letter. Also per the explainer, tuples map to records whose field names are unprefixed integers, and similarly for unions. So that's just inconsistent. But more broadly, are these restrictions a good idea?

I may have missed something, but the only stated justification for them I can find is that binding generators almost always need to re-case the words, and "[t]he highly-restricted character set ensures that capitalization is trivial and does not require consulting Unicode tables." I think it's highly unlikely that bindings generators will be running on platforms which are not capable enough to consult Unicode tables, or need to re-case enough distinct labels that the overhead of doing so becomes significant. (Most re-casings are trivial to memoize at the word level, at least if you also note whether the word in question is the first in the identifier or not. Some don't even require that information.) The only scenario I can think of in which bindings generators need to run on (moderately) low-powered devices is for JavaScript on mobile, but Unicode tables are already required there for the Internationalization API.

There is, of course, also that many programming languages do not support non-ASCII identifiers. But many do—JavaScript, of course, but also Rust, Python, Java, C#... There are active efforts to run all of these languages in WebAssembly. And while non-ASCII identifiers are perhaps not yet in common use due to the dominance of English in computing, enforcing that dominance on a technical level is, frankly, wrong. (Or, perhaps, they're more common than I'm aware, as a native English speaker?)

If these restrictions are maintained into release, there is a chance that bindings generators will come up with a separate, likely informal convention for expressing incompatible identifiers, as well.

This argument extends to the requirement that words start with a letter—most any language permits digits after an underscore, and Rust uses bare integers for tuple fields, which I bet was the inspiration for the CM doing the same. Dealing with these issues is probably less important (modulo the inconsistency around tuples and unions), but they're close enough to the point of this issue that I think it's worth raising them at the same time.

Start with the explainer sections defining word and the tuple and union mappings. Review how the naming restrictions relate to binding generators and the existing inconsistency around numeric field names, then follow the 15-comment discussion for the current position. Done requires a resolved design decision and corresponding specification updates, if any.