Squeezing decorators into functional extensions
IMO the first version is easier to maintain, and I don't see from the shown code, what you gain by the second.



In the second version:

Each FileProvider class doesn't need to explicitly inherit IDecorable&lt;IFileProvider&gt; because that is inherited via IFileProvider.



I maybe overlooking something or you may find it too obvious to show, but I don't like that you implement the interface IFileProvider in all the provider classes, because they then are forced to implement all (I can see there aren't any (yet)) possible common members, which could be taken care of in a base class. Therefore I would create an abstract base class for the providers like:

  interface IDecorable&lt;T&gt;
  {
    T DecorateWith(Func&lt;T, T&gt; createDecorator);
  }

  interface IFileProvider : IDecorable&lt;IFileProvider&gt;
  {

  }

  abstract class FileProvider : IFileProvider
  {
    public virtual IFileProvider DecorateWith(Func&lt;IFileProvider, IFileProvider&gt; createDecorator)
    {
      return createDecorator(this);
    }
  }

  class PhysicalFileProvider : FileProvider
  {
    public static PhysicalFileProvider Create()
    {
      return new PhysicalFileProvider();
    }
  }

  class RelativeFileProvider : FileProvider
  {
    public RelativeFileProvider(IFileProvider fileProvider, string basePath)
    {

    }

    public static Func&lt;IFileProvider, RelativeFileProvider&gt; Create(string basePath)
    {
      return decorable =&gt; new RelativeFileProvider(decorable, basePath);
    }
  }
  ...


In this way you gain both the benefits of normal OOP inheritance/polymorphic behavior and the decorator pattern and at the same time are still free to chain .DecorateWith(...) with other implementers of IFileProvider



Madness is a strong word. The shown chain looks a little nicer than a chain of new xx() statements, and you explicitly "explain" the pattern and behavior. And the first version doesn't need much attention when first written, so no harm done at least.