interface ISimpleInterfaceFirst
    {
        /* Mandatory members */
    }

    static class ISimpleInterfaceFirstExtensions
    {}

    interface ISimpleInterfaceSecond
    {
        /* Mandatory members */
    }

    static class ISimpleInterfaceSecondExtensions
    {}

    interface IComplexInterface
    {
        /* Mandatory members */
    }

    static class IComplexInterfaceExtensions
    {
        private static void InitializeGuard(this IComplexInterface s)
        {
            if (!(s is ISimpleInterfaceFirst && s is ISimpleInterfaceSecond))
                throw new Exception("Bad usage");
        }

        private static ISimpleInterfaceFirst GetSimpleInterfaceFirst(this IComplexInterface s)
        {
            return s as ISimpleInterfaceFirst;
        }

        private static ISimpleInterfaceSecond GetSimpleInterfaceSecond(this IComplexInterface s)
        {
            return s as ISimpleInterfaceSecond;
        }

        public static void ExtensionMethod(this IComplexInterface s)
        {
            s.InitializeGuard();

            //Logic using ISimpleInterfaceFirst and ISimpleInterfaceSecond via GetSimpleInterfaceFirst and GetSimpleInterfaceSecond
        }
    }

    //Делаем доступными операции из обоих интерфейсов
    class SimpleLogic: ISimpleInterfaceFirst, ISimpleInterfaceSecond
    {}

    //Делаем доступными операции из обоих интерфейсов + операции, требующий реализацию обоих интерфейсов
    class ComplexLogic: ISimpleInterfaceFirst, ISimpleInterfaceSecond, IComplexInterface
    {}

interface IComplexInterface : ISimpleInterfaceFirst, ISimpleInterfaceSecond
// или
public void Do<T>(T arg)
  where T: ISimpleInterfaceFirst, ISimpleInterfaceSecondExtensions

DO favor defining classes over interfaces.
Class-based APIs can be evolved with much greater ease than interface-based APIs because it is possible to add members to a class without breaking existing code.

" KRZYSZTOF CWALINA Over the course of the three versions of the .NET Framework, I have talked about this guideline with quite a few developers on our team. Many of them, including those who initially disagreed with the guideline, have said that they regret having shipped some API as an interface. I have not heard of even one case in which somebody regretted that they shipped a class.

" JEFFREY RICHTER I agree with Krzysztof in general. However, you do need to think about some other things. There are some special base classes, such as MarshalByRefObject. If your library type provides an abstract base class that isn't itself derived from MarshalByRefObject, then types that derive from your abstract base class cannot live in a different AppDomain.

...

DO use abstract classes instead of interfaces to decouple the contract from implementations.
Abstract classes, if designed correctly, allow for the same degree of decoupling between contract and implementation.

" BRIAN PEPIN Another sign that you've got a well-defined interface is that the interface does exactly one thing. If you have an interface that has a grab bag of functionality, that's a warning sign. You'll end up regretting it because in the next version of your product you'll want to add new functionality to this rich interface, but you can't.

" KRZYSZTOF CWALINA I often hear people saying that interfaces specify contracts. I believe this is a dangerous myth. Interfaces, by themselves, do not specify much beyond the syntax required to use an object. The interface-as-contract myth causes people to do the wrong thing when trying to separate contracts from implementation, which is a great engineering practice. Interfaces separate syntax from implementation, which is not that useful, and the myth provides a false sense of doing the right engineering. In reality, the contract is semantics, and these can actually be nicely expressed with some implementation.

class SuperLogic: Base, IInterfaceX, IInterfaceY {}

class SuperLogic: Base, IInterfaceX, IInterfaceY, IInterfaceZ {}

S>interface IComplexInterface : ISimpleInterfaceFirst, ISimpleInterfaceSecond
S>// или
S>public void Do<T>(T arg)
S>  where T: ISimpleInterfaceFirst, ISimpleInterfaceSecondExtensions
S>

    static class IComplexInterfaceExtensions
    {
        public static void ExtensionMethod<T>(this T s) where T: ISimpleInterfaceFirst, ISimpleInterfaceSecond
        {}
    }

S>Неудобно? Ну а смысл тогда писать код, которым самому неудобно пользоваться, я уж про пользователей молчу?

S>3. Если снова нет — рассмотрите любой язык с динамической типизацией, в шарпе всё-таки падать в последний момент, без жалоб в момент компиляции, не принято

    class ComplexLogic: ISimpleInterfaceFirst, IComplexInterface//ISimpleInterfaceSecond(так не надо делать :))
    {}

Если контракт одинаков для нескольких реализаций — ничего не мешает выделить контракт в интерфейс и подменять реализации по мере необходимости. Однако само по себе наличие/отсутствие интерфейса ничего не гарантирует, за "качество" абстракции отвечает разработчик. Поэтому контракт Dictionary хорош сам по себе, вне зависимости от наличия/отсутствия IDictionary, а TraceSource (даже если его спрятать за ITraceSource) — нет.