...but should it? ${number} admits strings like "-1.0e1", which a number index signature does not (since such a string, while parseable as a number, does not fill a numeric slot on the object!).

I recall that I read something about the requirement for ${number} in template literal types to round-trip (parsing as number and stringifying gives the same string).
But testing with const a: `${number}` = '1.0'; shows that this is not the case.

The round-tripping is not a requirement, so @weswigham 's analysis is correct

@RyanCavanaugh said

The round-tripping is not a requirement

Hmm, seems like it should be, right? I'd expect `${number}` to correspond exactly to those values `${n}` where n is of type number. Of course, we already look the other way with things like NaN and Infinity, so maybe not. In any case, has the round-trip functionality actually been discussed and declined? Or did it merely not get implemented yet? Is there an existing issue to track it? If not, should I open one?

Hmm, seems like it should be, right? I'd expect ${number} to correspond exactly to those values ${n} where n is of type number

This would imply that "1.0" wouldn't be a valid ${number}, which I think would be extraordinarily surprising.

Wow, my intuition is exactly the opposite; could you articulate why it would be surprising? You must be looking at the class of valid string-to-number inputs, while I'm looking at the class of valid number-to-string outputs, and both of us are thinking "yep, that's the natural meaning of `${number}`". What's the intuition that drives your view?

Mine is that template literal types should correspond to (untagged) template literal values. Such template literals can consume numbers and produce strings, but they don't consume strings to produce numbers. If "1.0" and "0xfacade" are valid `${number}` values, then the type `${number}` doesn't have much, if anything, to do with template literals at all. It's more like "the strings s where Number(s) or +s is not NaN". It gets worse for a type like `foo${number}bar`: you need to say something like "those strings `foo${s}bar` where s is a string where +s is not NaN", instead of the much more straightforward "those strings `foo${n}bar` where n is a number".

Furthermore, the set of valid number-to-string outputs has a use case we already care about in TypeScript: "numeric" object indices. And while the set of string-to-number inputs might be useful, we don't currently have a string-to-number type function (as in #26382) to use with it. So I'd be interested in seeing use cases where the prohibition of "1.0" and "0xfacade" would break things.

I ran a poll and most people seem to have the reverse interpretation https://twitter.com/SeaRyanC/status/1420059847156928512

Oh, well, 78.6% of respondents are wrong! Kidding, kind of. I guess `${number}s` don't lie! But I wonder if you'd have gotten different results if you had asked about

let s4: `${number}%` = "0xfacade%"; // okay or error
(arr: string[], idx: `${number}`) => arr[idx]; // okay or error
let s5: `This sentence is ${boolean}` = "This sentence is 0"; // okay or error
let s6: `${100.0}%` = "100.0%"; // okay or error

instead. In any case, this really makes me wish we had a different notation for strings-that-are-coercible-to-finite-numbers (maybe a new intrinsic type like type numericLiteralString = intrinsic) because the current notation is hard to square with how it's being used.