Issue 1:
TL;DR: provide a syntax which kills this compiler error:

Class 'D' incorrectly implements interface 'C'.
Property '_a' is protected but type 'D' is not a class derived from 'C'.

If the implementer wants to take responsibility for making sure the private members behave correctly they should be able to do so.

This would allow mixins to have protected members and solve a few issues with other multiple inheritance use-cases.

Proposal: Allow implementation of protected and private members in derived and implementing classes

Allow interface implementers to implement protected and private methods. This makes it possible for types with private and protected members to be implemented as interfaces (provided the inheritor correctly manages the private state).

Suggested syntax:

class P {private _p;}
class Q implements P { private _p implements P; }

Since name mangling is not used we can't alias the private members, so if implementing more than one interface with private members, the private members must either have different names, or the underlying uses of the members must be compatible, or be made compatible.

class P{private _p;}
class P2{private _p;}
class Q implements P, P2{ private _p implements P, P2;}

Of course interfaces can have protected and private members, though they can't declare them directly and you can't implement them directly:

class P { protected _p = "p"; }
interface Q extends P { q; };
// Q can't be implemented except by a class derived from P
class PX extends P implements Q { q = "q"; }
class R { protected _r = "r"; }
interface S extends Q, R { s; }
// S cannot be implemented by anyone
// However you could gin up the correct members, and cast to S
function SFactory(): S { var px = new PX(); px["s"] = "s"; px["_r"] = "r"; return <S>px; }
// you can even make it constructable:
class _S extends PX {
s = "s";
protected _r = "r";
}

var S: new (...args) => S = <new (...args) => S><new()=> any>_S;
var myS = new S();

I understand the explanation given in #471, that we cannot simply ignore the private members, as e.g. other instances of B need to be able to access B's private members on C. However protected members are part of the API contract too, for inheritors, and we should be able to implement them.

What's more, nothing is truly private in JavaScript. This can be achieved in typescript using the ["_p"] escape hatch and an intermediate class as above.

Motivation

Several uses for this. One is that it seems to be the only way to allow mixins to have private or protected members.

I'm working with a large library, and have come across the following situation, where I need a type which implements two classes/interfaces which derive from a common base.

Given these classes:

interface A { a; }
class B implements A {
protected _a; get a() { return this._a; }
BFunc() { };
}
class C implements A {
protected _a; get a() { return this._a; }
CFunc() { };
}

I need then to create a class implementing both B and C. Note that both B and C have chosen to implement a using a protected backing member _a, and that these are compatible implementations with exactly the same meaning. There is now no way to achieve this.

Allowing interfaces to declare protected members would make them part of the API contract for inheritors and would solve this problem.

This does not work:

// Class 'D' incorrectly implements interface 'C'.
// Property '_a' is protected but type 'B' is not a class derived from 'C'.
class D extends B implements C {
CFunc() { };
}

Neither does this:

// Class 'E' incorrectly implements interface 'B'.
// Property '_a' is protected but type 'E' is not a class derived from 'B'.
// Class 'E' incorrectly implements interface 'C'.
// Property '_a' is protected but type 'E' is not a class derived from 'C'.
class E implements B, C {
_a;
get a() { return this._a; }
BFunc() { };
CFunc() { };
}

For example if I could reopen the interface like so:

interface A { protected _a;}

That would solve the issue. By declaring it part of the API contract, albeit one only accessible to inheritors, we solve the problem.

Currently the only way to work around involves making the backing member public in the interface, or public in the derived classes. (There has to be a backing member in this case). Even making the A a class, and declaring the protected member won't allow you to do it.

Issue 2:
It seems like the rules for a) implementing multiple interfaces and b) intersection types should be consistent.

Example 1: Optional members

interface A { m1: string;}
interface B { m1?: string;}
// allowed, m1 is required.
type CT = A&B;
var a : CT = {m1:undefined};// allowed, string can be undefined
// error, m1 is required,
//TS2322: Type '{}' is not assignable to type 'A & B', Property 'm1' is missing in type '{}'.
var b : CT = {};

// not allowed, TS2320, Named property 'm1' of types 'A' and 'B' are not identical.
interface C extends A, B {}

Example 2: Protected members

class P { protected m1: number; }
class Q { m1: number; }
// allowed, m1 is public
type PQT = P&Q;
var p : PQT = <PQT>{m1:undefined};
p.m1; // allowed, m1 is public in PQT

// not allowed
// TS2420: Class 'PQ' incorrectly implements interface 'Q'
// Property 'm1' is protected in type 'PQ' but public in type 'Q'.
class PQ extends P implements Q {}
// TS2420: Class 'QP' incorrectly implements interface 'P'.
// Property 'm1' is protected but type 'Q' is not a class derived from 'P'.
class QP extends Q implements P {}

// Allowed to relax protection explicitly in a derived class
class PQX extends P implements Q { m1: number;}

// Not allowed - again, seems a bug.
class QPX extends Q implements P { m1: number;}

// Workaround is to use an intermediate class to relax the protection
class PX extends P {m1: number;}
class QPX2 extends Q implements PX { m1: number;}

Implementing multiple interfaces should create a type which is the intersection of the types of the interfaces (but with any new members added).

It should not be an error to make an optional member non-optional in a derived class. Non-optional members can be undefined, so nothing should break. This is consistent with intersection types. (Arguably also vice versa.)

It should not be an error to relax the protected or private status of a member in a derived or implementing class, consistent with intersection types. (in 1.6 you can do it in a derived class but not an implementing class). Or at any rate it should be possible to do so if you need to. See also #3854

(Surely from a strict point of view Q above is a subtype of P, because it can be used wherever P is used. All members visible externally on P are visible externally on Q, and all members visible internally on P are visible internally on Q. So I think that makes Q a subtype of P.)

Implementing two or more interfaces should create the same type as the intersection of the types. That they don't seems like a bug.

In pseudocode, this:

interface C extends A, B {}

Should be identical in effect to this (if it was a thing):

type C1 = A & B;
interface C extends C1 {}