Unexpected behaviour of Typescript Record<number, Type> type

I was playing around with the Record type, when I found out something which wasn't what I was expected to be. I am in Typescript 5.16.

If I have a Record<string, T> type, and I have this object

const a: Record<string, T> = {
  123: someData,
  x: someData
}

Then this works. This is probably because in javascript, number indices on objects are actually coerced to string, so this is somewhat an expected behaviour.
However, if I add a symbol type as a key, it does not error at all (and to my knowledge, symbols don't get coerced to anything). Even if I have a Record<number, T>, it accepts symbols as keys along with only numeric indices.
What even more confuses me is that if I do something like

const a: Record<number, T> = {
  123: someData,
  [Symbol.for("ABCD")]: someData
}

it compiles perfectly fine, but if I give a pre built symbol instead, like Symbol.iterator (only when key type is number as the last example), it errors as expected. See here.

Is there a reason for this last odd behaviour or am I missing anything?

Excess property checking in TypeScript is not really part of the type system. It's a nice-to-have feature and not a type-safety feature. It only happens in particular situations, and the lack of the feature outside these situations might be unfortunate, but it isn't a type safety hole.

Values are allowed to have more properties than required by their types; this is what enables interface and class hierarchies created via extension to act as type hierarchies. Example:

interface Foo { fooProp: string }
interface Bar extends Foo { barProp: string }
const bar: Bar = { fooProp: "", barProp: "" };
const foo: Foo = bar; // okay

Every Bar is a valid Foo, even though the Foo type doesn't know about barProp. If extra properties were prohibited, then Bar would not be compatible with Foo.

Instead, excess property checks are a linter-like feature that tries to prevent mistakes in which the compiler "forgets" about properties in object literals:

const otherFoo: Foo = { fooProp: "", barProp: "" }; // error!
// --------------------------------> ~~~~~~~
//   Object literal may only specify known properties, 
// and 'barProp' does not exist in type 'Foo'.(2322)

The reason why you get an error there isn't because barProp is "invalid" for a Foo; after all, the foo variable above has it. It's because the compiler will forget all about otherFoo's barProp property, and that might be a mistake. That isn't the case for foo, since even though you can't access foo.barProp directly, you can access the same value via bar.barProp.

But again, excess property checking sometimes doesn't happen, even in object literals.

One such place excess property checking doesn't seem to happen is with computed properties. See microsoft/TypeScript#36920. It is currently classified as a missing feature (although a similar issue was classified as a bug, so 🤷‍♂️).

If the compiler cannot infer a single literal type for a computed property, it tends to get widened to string or number or symbol, and is then simply ignored by excess property checks. So while otherFoo above gets an excess property warning, the following does not:

const anotherFoo: Foo = {
  fooProp: "",
  ["bar" + "Prop"]: "" // no error
}

The compiler does not know that "bar" + "Prop" is of type "barProp" (it does not perform type-level string concatenation via the + operator); it only knows that it is of type string. No excess property warning occurs, even though it is very unlikely for a random string to be one of the known keys of an interface.

The same thing happens with symbol-valued keys. If the symbol is a known unique symbol, then you get an excess property warning:

const uniqueSymbol = Symbol("abc");

const yetAnotherFoo: Foo = {
  fooProp: "",
  [uniqueSymbol]: "" // error, excess prop
}

But if you have a non-unique symbol whose type is just symbol, you don't get an excess property warning:

const nonUniqueSymbol: symbol = uniqueSymbol;

const oneMoreForTheRoad: Foo = {
  fooProp: "",
  [nonUniqueSymbol]: "" // no error
}

That is why you're seeing the behavior with Record<number, T>. Keys of type number are checked as expected, and literal-typed keys of non-number type in an object literal will get excess property warnings, but computed keys of widened, non-literal types do not.

A symbol key that is created inside a computed property isn't considered a unique symbol (you need to initialize a const with it, if you want it to be considered a unique symbol) and therefore treated as non-literal and you don't get a warning:

const a: Record<number, string> = {
  123: "", // okay
  [uniqueSymbol]: "", // error
  [Symbol.for("ephemeral and so not given a unique type")]: "" // okay
}

So that's the issue. Excess property checking doesn't apply to computed properties of non-literal types.

Playground link to code