Duplicate explicit interfaces cause emit error

interface I:
	def Foo()

class A(I):
	def I.Foo():
		print "A"

class B(A):
	def I.Foo():
		print "B"

test.boo(10,9): BCE0055: Boo.Lang.Compiler.CompilerError: Internal compiler error: Object reference not set to an instance of an object.. ---> System.NullReferenceException: Object reference not set to an instance of an object.
at Boo.Lang.Compiler.Steps.EmitAssembly.GetMethodInfo(IMethod entity)
at Boo.Lang.Compiler.Steps.EmitAssembly.OnMethod(Method method)
at Boo.Lang.Compiler.Ast.Method.Accept(IAstVisitor visitor)
at Boo.Lang.Compiler.Ast.DepthFirstVisitor.Visit(Node node)
— End of inner exception stack trace —
at Boo.Lang.Compiler.Ast.DepthFirstVisitor.OnError(Node node, Exception error)
at Boo.Lang.Compiler.Steps.AbstractVisitorCompilerStep.OnError(Node node, Exception error)
at Boo.Lang.Compiler.Ast.DepthFirstVisitor.Visit(Node node)
at Boo.Lang.Compiler.Ast.DepthFirstVisitor.Visit(Node[] array)
at Boo.Lang.Compiler.Ast.DepthFirstVisitor.Visit[T](NodeCollection`1 collection)
at Boo.Lang.Compiler.Steps.EmitAssembly.EmitTypeDefinition(TypeDefinition node)
at Boo.Lang.Compiler.Steps.EmitAssembly.OnClassDefinition(ClassDefinition node)
at Boo.Lang.Compiler.Ast.ClassDefinition.Accept(IAstVisitor visitor)
at Boo.Lang.Compiler.Ast.DepthFirstVisitor.Visit(Node node)
at Boo.Lang.Compiler.Ast.DepthFirstVisitor.Visit(Node[] array)
at Boo.Lang.Compiler.Ast.DepthFirstVisitor.Visit[T](NodeCollection`1 collection)
at Boo.Lang.Compiler.Steps.EmitAssembly.OnModule(Module module)
at Boo.Lang.Compiler.Steps.EmitAssembly.DefineTypes()
at Boo.Lang.Compiler.Steps.EmitAssembly.Run()
at Boo.Lang.Compiler.CompilerPipeline.RunStep(CompilerContext context, ICompilerStep step)

Test case is similar to BOO-1064, but makes it all the way to the emit stage, where another error occurs.

I did some poking around and found the error might be in ProcessInheritedAbstractMembers. ExplicitInfo needs to be bound in two ways: its InterfaceType is bound in ResolveTypeReferences, and it needs to be bound itself in ProcessInheritedAbstractMembers to the method that it implements. It doesn't always get set or checked.

The submitted patch attempts to make this an error, but it causes several unrelated test cases to fail for no reason I can see.