UPDATE for TS4.1+

The original answer still works (and you should read it if you need an explanation), but now that recursive conditional types are supported, we can write merge() with to be variadic:

type OptionalPropertyNames<T> =
  { [K in keyof T]-?: ({} extends { [P in K]: T[K] } ? K : never) }[keyof T];

type SpreadProperties<L, R, K extends keyof L & keyof R> =
  { [P in K]: L[P] | Exclude<R[P], undefined> };

type Id<T> = T extends infer U ? { [K in keyof U]: U[K] } : never

type SpreadTwo<L, R> = Id<
  & Pick<L, Exclude<keyof L, keyof R>>
  & Pick<R, Exclude<keyof R, OptionalPropertyNames<R>>>
  & Pick<R, Exclude<OptionalPropertyNames<R>, keyof L>>
  & SpreadProperties<L, R, OptionalPropertyNames<R> & keyof L>
>;

type Spread<A extends readonly [...any]> = A extends [infer L, ...infer R] ?
  SpreadTwo<L, Spread<R>> : unknown

type Foo = Spread<[{ a: string }, { a?: number }]>

function merge<A extends object[]>(...a: [...A]) {
  return Object.assign({}, ...a) as Spread<A>;
}

And you can test it:

const merged = merge(
  { a: 42 },
  { b: "foo", a: "bar" },
  { c: true, b: 123 }
);
/* const merged: {
    a: string;
    b: number;
    c: boolean;
} */

Playground link to code

ORIGINAL ANSWER

The intersection type produced by the TypeScript standard library definition of Object.assign() is an approximation that doesn't properly represent what happens if a later argument has a property with the same name as an earlier argument. Until very recently, though, this was the best you could do in TypeScript's type system.

Starting with the introduction of conditional types in TypeScript 2.8, however, there are closer approximations available to you. One such improvement is to use the type function Spread<L,R> defined here, like this:

// Names of properties in T with types that include undefined
type OptionalPropertyNames<T> =
  { [K in keyof T]: undefined extends T[K] ? K : never }[keyof T];

// Common properties from L and R with undefined in R[K] replaced by type in L[K]
type SpreadProperties<L, R, K extends keyof L & keyof R> =
  { [P in K]: L[P] | Exclude<R[P], undefined> };

type Id<T> = T extends infer U ? { [K in keyof U]: U[K] } : never // see note at bottom*

// Type of { ...L, ...R }
type Spread<L, R> = Id<
  // Properties in L that don't exist in R
  & Pick<L, Exclude<keyof L, keyof R>>
  // Properties in R with types that exclude undefined
  & Pick<R, Exclude<keyof R, OptionalPropertyNames<R>>>
  // Properties in R, with types that include undefined, that don't exist in L
  & Pick<R, Exclude<OptionalPropertyNames<R>, keyof L>>
  // Properties in R, with types that include undefined, that exist in L
  & SpreadProperties<L, R, OptionalPropertyNames<R> & keyof L>
  >;

(I've changed the linked definitions slightly; using Exclude from the standard library instead of Diff, and wrapping the Spread type with the no-op Id type to make the inspected type more tractable than a bunch of intersections).

Let's try it out:

function merge<A extends object, B extends object>(a: A, b: B) {
  return Object.assign({}, a, b) as Spread<A, B>;
}

const merged = merge({ a: 42 }, { b: "foo", a: "bar" });
// {a: string; b: string;} as desired

You can see that a in the output is now correctly recognized as a string instead of string & number. Yay!

But note that this is still an approximation:

• Object.assign() only copies enumerable, own properties, and the type system doesn't give you any way to represent the enumerability and ownership of a property to filter on. Meaning that merge({},new Date()) will look like type Date to TypeScript, even though at runtime none of the Date methods will be copied over and the output is essentially {}. This is a hard limit for now.

• Additionally, the definition of Spread doesn't really distinguish between missing properties and a property that is present with an undefined value. So merge({ a: 42}, {a: undefined}) is erroneously typed as {a: number} when it should be {a: undefined}. This can probably be fixed by redefining Spread, but I'm not 100% sure. And it might not be necessary for most users. (Edit: this can be fixed by redefining type OptionalPropertyNames<T> = { [K in keyof T]-?: ({} extends { [P in K]: T[K] } ? K : never) }[keyof T])

• The type system can't do anything with properties it doesn't know about. declare const whoKnows: {}; const notGreat = merge({a: 42}, whoKnows); will have an output type of {a: number} at compile time, but if whoKnows happens to be {a: "bar"} (which is assignable to {}), then notGreat.a is a string at runtime but a number at compile time. Oops.

So be warned; the typing of Object.assign() as an intersection or a Spread<> is kind of a "best-effort" thing, and can lead you astray in edge cases.

Playground link to code

*Note: Id<T> is an identity type and in principle shouldn't do anything to the type. Someone at some point edited this answer to remove it and replace with just T. Such a change isn't incorrect, exactly, but it defeats the purpose... which is to iterate through the keys to eliminate intersections. Compare:

type Id<T> = T extends infer U ? { [K in keyof U]: U[K] } : never 

type Foo = { a: string } & { b: number };
type IdFoo = Id<Foo>; // {a: string, b: number }

If you inspect IdFoo you will see that the intersection has been eliminated and the two constituents have been merged into a single type. Again, there's no real difference between Foo and IdFoo in terms of assignability; it's just that the latter is easier to read in some circumstances.

Seems like this should do the trick:

var objectA = {
    propertyA: 1,
    propertyB: 2,
    .
    . // more properties here
    .
    propertyM: 13
};

var objectB = {
    propertyN: 14,
    propertyO: 15,
    .
    . // more properties here
    .
    propertyZ: 26
};

var objectC = {...objectA, ...objectB}; // this is the answer

var a = objectC.propertyA;

var n = objectC.propertyN;

Based on this article: https://blog.mariusschulz.com/2016/12/23/typescript-2-1-object-rest-and-spread

In addition, the order of the variables in the decomposition matters. Consider the following:

var objectA = {
    propertyA: 1,
    propertyB: 2, // same property exists in objectB
    propertyC: 3
};

var objectB = {
    propertyX: 'a',
    propertyB: 'b', // same property exists in objectA
    propertyZ: 'c'
};

// objectB will override existing properties, with the same name,
// from the decomposition of objectA
var objectC = {...objectA, ...objectB}; 

// result: 'b'
console.log(objectC.propertyB); 

// objectA will override existing properties, with the same name,
// from the decomposition of objectB
var objectD = {...objectB, ...objectA}; 

// result: '2'
console.log(objectD.propertyB); 

The any type is intentionally unsound. It acts as both a top type like unknown and as (nearly) a bottom type like the never type. any is assignable both to and from every other type (except that any is not assignable to never). That means many of the conditional types in your code will behave differently from your expectations if the type being checked is any. Your U[K] extends object check passes if U[K] is any. So does the U[K] extends any[] check. And the U[K] extends any check always passes.

So when U is {a: any} then your example code decides that the a property is an array and returns it. Oops.

If you want to handle any in a special way, you'll need to change your check.

The only reliable way I know how to do this is as described in Typescript check for the 'any' type and Disallow call with any and it takes advantage of the unsoundness. TypeScript will convert just about every union and intersection with any to any. Something like 1 extends (0 & T) seems like it's always false, since supposedly X extends (Y & Z) requires both X extends Y and Y extends Z. And since 1 extends 0 is false, that should always be false too. But if T is any, then 0 & T is also any (unsound, unsafe, but intended), and then 1 extends any is true. So you can use the unsoundness to detect any.

I will rewrite some relevant bits of your code:

type MergeTypesWithPriority<T, U> = 1 extends (T & U & 0) ? T : { // <--
    [K in keyof T | keyof U]: K extends keyof T
        ? K extends keyof U
            ? T[K] extends object
                ? U[K] extends object
                    ? T[K] extends any[]
                        ? T[K]
                        : U[K] extends any[]
                            ? 1 extends (U[K] & 0) ? T[K] : U[K] // <--
                            : MergeTypesWithPriority<T[K], U[K]>
                    : T[K]
                : T[K]
            : T[K]
        : K extends keyof U
            ? U[K] extends object
                ? T extends Record<K, any> 
                    ? 1 extends (U[K] & 0) // <--
                        ? T[K]
                        : U[K]
                    : U[K]
                : U[K]
            : never;
};

The check at the top bails out early if either T or U are any, and returns T if so. The check in the middle fixes the problem you had with misclassifying any as an array, by just returning T[K] if U[K] is any before proceeding. The check at the bottom changes your U[K] check so it actually looks for any (although I didn't see any examples where it matters).

Let's test your code:

type t11 = Expect<Equal<
  MergeTypesWithPriority<{ a: Items }, { a: any }>, 
  { a: Items }>
>; // okay

All your other tests pass, and now this one does also.

Playground link to code