Append an extra member to an object - type intersection vs iteration approach

Here is the question: AppendToObject. My first intuition to the question was to use type intersection, e.g,

type AppendToObject<T, U extends PropertyKey, V> = T & {[P in U]: V}

However, that solution doesn't pass the testcases.

type test1 = {
  key: 'cat'
  value: 'green'
}

type testExpect1 = {
  key: 'cat'
  value: 'green'
  home: boolean
}

type test2 = {
  key: 'dog' | undefined
  value: 'white'
  sun: true
}

type testExpect2 = {
  key: 'dog' | undefined
  value: 'white'
  sun: true
  home: 1
}

type test3 = {
  key: 'cow'
  value: 'yellow'
  sun: false
}

type testExpect3 = {
  key: 'cow'
  value: 'yellow'
  sun: false
  moon: false | undefined
}

// reference from 
// https://github.com/type-challenges/type-challenges/blob/main/utils/index.d.ts
type Equal<X, Y> =
  (<T>() => T extends X ? 1 : 2) extends
  (<T>() => T extends Y ? 1 : 2) ? true : false
type Expect<T extends true> = T

type cases = [
  Expect<Equal<AppendToObject<test1, 'home', boolean>, testExpect1>>,
  Expect<Equal<AppendToObject<test2, 'home', 1>, testExpect2>>,
  Expect<Equal<AppendToObject<test3, 'moon', false | undefined>, testExpect3>>,
]

So I changed to the iteraction approach and it passes all the testcases.

type AppendToObject<T, U extends PropertyKey, V> = {[P in U | keyof T ]: P extends keyof T ? T[P] : V}

I'm not seeing anything wrong with the intersection approach, as if I type an object with it, it's also compulsory to specify the extra argument. Does the solution fail the tests just because of how Equal is implemented? Or, is there any other nuances between these two approaches that I'm not aware?

The result types for the AppendToObject looks correct. So I suspect the issue is with how the Equal compares the types. Example:

type test1 = {
key: 'cat';
value: 'green';
};
type testExpect1 = {
key: 'cat';
value: 'green';
home: boolean;
};
// type Result = test1 & {
//     home: boolean;
// }
type Result = AppendToObject<test1, 'home', boolean>

So the testExpect1 has no intersection, but the property is directly in one object.

This can be fixed by using the Prettify utility type from the type-samurai package. Simplified version:

type Prettify<T> = T extends infer R
? {
[K in keyof R]: R[K];
}
: never;

Prettify remaps the type which causes to remove the intersection and make the more readable.

Testing:

type AppendToObject<T, U extends PropertyKey, V> = Prettify<
T & { [P in U]: V }
>;
// type Result = {
//   key: 'cat';
//   value: 'green';
//   home: boolean;
// }
type Result = AppendToObject<test1, 'home', boolean>;

playground