I don't yet have much personal experience writing D code but I have a strong suspicion that "extension methods" are superior to UFCS.

First I want to note that the Dr. Dobb's UFCS article (http://www.drdobbs.com/blogs/cpp/232700394) describes extension methods incorrectly. Extension methods can be called with infix notation or with function notation; marking a method as an extension method only increases the ways it can be used.

1. UFCS is not self-documenting. I assume that in most use cases, a function is intended either to be called as a function, or to be called via UFCS. D doesn't give us a way to express this intention.
2. As a result of #1, UFCS will pollute auto-complete lists and similar tools. Tools will probably end up needing to add tool-specific ways to mark up UFCS functions.
3. I think UFCS has pitfalls similar to C++'s conversion constructors, except D doesn't even have the "explicit" keyword to opt out of it and it's not limited to single-parameter functions.

If breaking backward compatibility is at all an option, I suggest requiring functions to opt in to UFCS syntax in some way. Probably by adding an attribute. If someone wants to use UFCS on a function that doesn't allow it, they might be allowed to declare an identical function with the attribute added which forwards the call. A template or keyword could automate this. Perhaps when old-style UFCS is deprecated a DMD flag could be added that automatically generates source files with the attribute added to functions with UFCS usage.

If it's too late to fix it or opt-in is undesirable, I suggest something like C++'s "explicit" keyword which allows us to disable UFCS for specific functions.

I was unable to find any good pre-existing discussion on these problems but please close this Issue without warning if it has already been thoroughly considered.