I’m not a TS team member, but I doubt very much they’d want to add a type parameter and make the types generic just to specify the value of toStringTag. My guess is this issue gets closed as Design Limitation or Working as Intended, but you’ll probably have to wait until Monday for an official response.

This is the intended behavior; subclassing is subtyping and a class that returns a different value for [Symbol.toStringTag] is indeed not a subtype.

I would recommend writing

class Bytes extends Uint8Array {
  get [Symbol.toStringTag]() {
    return 'Bytes' as any;
  }
}

if you intend to make a new class with a subtyping violation (no judgment 😅).

If you’re trying to get the "Bytes" wired through the type system, there are ways of accomplishing that, but I won’t go into it unless you’re really interested since they’re rather involved.

To be clear, this is a bug and #48617 is a feature request. Normally you wouldn’t create a bug in order to work-around the lack of a feature. That’s why it’s not clear to me that this bug is intentional, as you are suggesting.

In any event, I wonder if this can be fixed by adding a type-param? That way the normal non-extended case would continue to work as desired, but if you needed to extend you could provide a type param for the toStringTag return. Something like:

class Bytes extends Uint8Array<'Bytes'> {
  get [Symbol.toStringTag]() {
    return 'Bytes';
  }
}

Or perhaps another interface to keep the regular Uint8Array use-case cleaner?

class Bytes extends ExtendedableTypedArray<Uint8Array, 'Bytes'> {
  get [Symbol.toStringTag]() {
    return 'Bytes';
  }
}