This isArrayLikeType(parentType) check is at fault here: https://github.dev/microsoft/TypeScript/blob/fbd63e9e43dc4e64184b590fa156002a7be6d47e/src/compiler/checker.ts#L10376

I’m not quite sure how this should be adjusted though. Currently isArrayLikeType is defined like this:

    function isArrayLikeType(type: Type): boolean {
        // A type is array-like if it is a reference to the global Array or global ReadonlyArray type,
        // or if it is not the undefined or null type and if it is assignable to ReadonlyArray<any>
        return isArrayType(type) || !(type.flags & TypeFlags.Nullable) && isTypeAssignableTo(type, anyReadonlyArrayType);
    }

In general, tuples and arrays are not always handled in the compiler in various scenarios - one of other things that comes to my mind is that intersections with tuple/array members are not always handled as expected (although that works in this particular scenario). So perhaps a fix here should involve a more general overhaul of how those things are treated within the compiler instead of being an ad-hoc change to satisfy this particular scenario.

In user code, I’d recommend using a newer version of Omit that is homomorphic:

type MappedOmit<T, K> = { [P in keyof T as P extends K ? never : P]: T[P] };

But yeah the behavior describes seems a little off

Found it! The issue seems to happen when one of the tuple type members is assignable to the other. For instance:

declare const bar: Omit<[number, 1], "at">
const [c, d] = bar
//     ^?
   c;
// ^? number

// ❌ This should be `1`
   d;
// ^? number

Instead of 1, d was typed as number, which I would assume TS is reducing from number | 1. It’s easier to see when the elements are functions:

declare const bar: Omit<[(x: number) => void, (x: 1) => void], "at">
const [c, d] = bar
//     ^?

// ❌ This should be `(x: number) => void`
   c;
// ^? (x: number) => void | (x: 1) => void

   d;
// ^? (x: 1) => void

And that kind of makes sense: here, c is typed as accepting either a number or specifically 1; the latter type is just redundant. In fact, if you give them different return types so it’s not redundant, you actually get the right type and not a union.

…And it’s at this point in the writeup that I discover the actual problem (sort of). All you need to do to “fix” this is to change your target to ES2021 or earlier. This problem only appears to occur while targeting ES2022 and ESNext. I have no idea if that’s intentional. My gut feeling is that it’s a bug, because it seems to behave in ways that can’t be right, but I suppose it’s possible TS is just expressing something that’s new in ES2022 that I’m not thinking of. (I’ve been surprised before…)

Here’s the issue reduced to something actually incorrect. Bizarrely, the type of the value changes depending on whether it’s called as a function: when it’s used in a function call, it picks of the union members, but it somehow picks the wrong one.

declare const bar: Omit<[(x: number) => void, (x: 1) => void], "at">
const [c, d] = bar
//     ^?

// ❌ This should be `(x: number) => void`
   c;
// ^?

// ❌ This should also be `(x: number) => void`, and it should accept a 2
   c(2);
// ^?

   d;
// ^?

@so1ve That’s just the same thing I already pointed out above: declaration site shows string | number, later uses have the proper type: Playground

Here’s a playground link for you.