diff --git a/docs/language/informal/interface-conflicts.md b/docs/language/informal/interface-conflicts.md
new file mode 100644
index 00000000000..cd1d7f313fb
--- /dev/null
+++ b/docs/language/informal/interface-conflicts.md
@@ -0,0 +1,275 @@
+# Feature Specification: Interface Conflict Management
+
+**Owner**: eernst@
+
+**Status**: Under discussion.
+
+**Version**: 0.3 (2018-04-24)
+
+
+This document is a Dart 2 feature specification which specifies how to
+handle conflicts among certain program elements associated with the
+interface of a class. In particular, it specifies that multiple occurrences
+of the same generic class in the superinterface hierarchy must receive the
+same type arguments, and that no attempts are made at synthesizing a
+suitable method signature if multiple distinct signatures are provided by
+the superinterfaces, and none of them resolves the conflict.
+
+
+## Motivation
+
+In Dart 1, the management of conflicts during the computation of the
+interface of a class is rather forgiving. On page 42 of
+[ECMA-408](https://www.ecma-international.org/publications/files/ECMA-ST/ECMA-408.pdf),
+we have the following:
+
+> However, if the above rules would cause multiple members
+> _m1, ..., mk_
+> with the same name _n_ to be inherited (because identically named
+> members existed in several superinterfaces) then at most one member
+> is inherited.
+>
+> ...
+>
+> Then _I_ has a method named _n_, with _r_ required parameters of type
+> `dynamic`, _h_ positional parameters of type `dynamic`, named parameters
+> _s_ of type `dynamic` and return type `dynamic`.
+
+In particular, the resulting class interface may then contain a method
+signature which has been synthesized during static analysis, and which
+differs from all declarations of the given method in the source code.
+In the case where some superintenfaces specify some optional positional
+parameters and others specify some named parameters, any attempt to
+implement the synthesized method signature other than via a user-defined
+`noSuchMethod` would fail (it would be a syntax error to declare both
+kinds of parameters in the same method declaration).
+
+For Dart 2 we modify this approach such that more emphasis is given to
+predictability, and less emphasis is given to convenience: No class
+interface will ever contain a method signature which has been
+synthesized during static analysis, it will always be one of the method
+interfaces that occur in the source code. In case of a conflict, the
+developer must explicitly specify how to resolve the conflict.
+
+To reinforce the same emphasis on predictability, we also specify that
+it is a compile-time error for a class to have two superinterfaces which
+are instantiations of the same generic class with different type arguments.
+
+
+## Syntax
+
+The grammar remains unchanged.
+
+
+## Static Analysis
+
+We introduce a new relation among types, _more interface-specific than_,
+which is similar to the subtype relation, but which treats top types
+differently.
+
+- The built-in class `Object` is more interface-specific than `void`.
+- The built-in type `dynamic` is more interface-specific than `void`.
+- None of `Object` and `dynamic` is more interface-specific than the other.
+- All other subtype rules are also valid rules about being more
+ interface-specific.
+
+This means that we will express the complete rules for being 'more
+interface-specific than' as a slight modification of
+[subtyping.md](https://github.com/dart-lang/sdk/blob/master/docs/language/informal/subtyping.md)
+and in particular, the rule 'Right Top' will need to be split in cases
+such that `Object` and `dynamic` are more interface-specific than `void` and
+mutually unrelated, and all other types are more interface-specific than
+both `Object` and `dynamic`.
+
+*For example, `List