(1) I discussed here and I do not even know what's going on there: https://news.ycombinator.com/item?id=24168274

Tho, your own example of immutable collections is actually a good one. Rather specific, but still good. Immutable collections really could profit from compuiler-level warnings or even errors. It would be an easy enough fix for the language/compiler team: have some attribute that you/the immutable library authors would decorate functions with, something like [NoDiscardReturn] and the compiler would check that and emit warnings/errors.

(2) Implementing something like IComparer<> is something you rarely do, and more or less never the way the author does.

   var enumerator = array.OrderBy(e => e.Foo).ThenBy(e => something.CheckProperty(e.Bar)).ThenByDescending(e => e.Name, StringComparer.OridinalIgnoreCase);
   array = enumerator.ToArray();
   // Tho you often do not need to call .ToArray() if you're only gonna traverse the enumerator once

Using Linq like this is more idiomatic and also kinda "functional", which appears to be what the author is after.

Now, this was specific to the comparer stuff, but in general a sane API these days would use Func<> or Action<> instead of single-method interfaces. There are still some leftovers in the C# stdlib (and probably more in third party libraries) but again, you can write a wrapper once - not the horrible mess the author proposed either, but an interface implementation that would use single Func<> parameter in the constructor and then call that in the method implementation.

    internal class Foo
    {
      public string Bar;
      public int Baz;

      public override string ToString() => $"{Bar}: {Baz}";
    }

    internal class DontAnnoyMeComparer<T> : IComparer<T>
    {
      private readonly Func<T, T, int> cmpFunc;

      internal DontAnnoyMeComparer(Func<T, T, int> cmpFunc)
      {
        this.cmpFunc = cmpFunc;
      }

      public int Compare(T x, T y) => cmpFunc(x, y);
    }

    static void Main(string[] args)
    {
      var foos = new[] {
         new Foo { Bar = "World", Baz = 1 },
         new Foo { Bar = "Hello", Baz = 2 },
         new Foo { Bar = "Hello", Baz = 1 },
       };

      // First with some ideomatic Linq
      Console.WriteLine(string.Join(", ", foos.OrderBy(f => f.Bar).ThenBy(f => f.Baz)));

      // Then with our helper interface implementation
      Array.Sort(foos, new DontAnnoyMeComparer<Foo>((x, y) => {
        var res = x.Bar.CompareTo(y.Bar);
        return res != 0 ? res : x.Baz.CompareTo(y.Baz);
      }));
      Console.WriteLine(string.Join(", ", (object[])foos));
    }

    // Output
    // Hello: 1, Hello: 2, World: 1
    // Hello: 1, Hello: 2, World: 1

(3) related directly to (2). The only real reason this is a real-world problem for the author is that they do not actually write idiomatic code.

(4) Sure, something like that would be nice sometimes. But the lack of it is hardly the end of the world. Tho on the flipside, in my opinion languages that offer such pseudo-DSLs or even real embdeddable DSLs quite often suffer from people writing DSLs for every freaking thing, thus reducing readability of their code.

(5) dynamic is hell for robust code, that's why you avoid it. I only ever used it when I was too lazy to do the extra typing to create proper types in run-once code dealing with JSON. And even then I should have probably just:

    class MyType {
      [DataMemeber]
      public int Foo;
      
      [DataMemeber(Name="baz")]
      public int Baz;
    }