>>> Except that you can't, because arrays, most frequent iterables in the language, do not expose iterator interface.

You seem to have a very narrow definition of interface (as a set of methods in an object). In fact, the interface that both arrays and Iterators implement is foreach and accompanying functions (key, next, etc.). What you probably imply by interface (Iterator) is a specific implementation of this interface.

>>> "custom foreach that works with evereything in the language"

You definitely could do that, I see no reason why not. You just can't do it with Iterator interface because it's not everything - unlike Ruby, not everything in PHP is an object.

>>> You also arbitrarily assign making and not making sense to things

It's not arbitrary, it's driven by 18 years of actual usage patterns. You may have other notions about what the users should want - but experience teaches us about what they do want.

>>> it would be nice to support destructuring in definitions of functions formals.

Well, that's a bit different topic. I don't believe list()-type destructuring would be very useful, since it's basically just making code more complicated without actually adding any facility not available otherwise. OTOH, destructuring in form of named arguments support in some form - allowing unbounded option lists to be handled easily and naturally - may be useful, and it is one of a real things that is missing - that is a true deficiency of PHP which I know and recognize. I hope it will be fixed one day.

>>> You basically believe that generic pattern matching is unnecessary because PHP doesn't have it.

Nope, I believe it is unnecessary in PHP because nobody has demonstrated a common PHP use case that is hard to solve in PHP without it. If somebody does, I may change my opinion.

>>> You said nothing about error handling strategies in PHP.

Frankly, I didn't notice that. But yes, there are two ways of dealing with errors in PHP - OOP way (exceptions) and non-OOP way (return codes). This is because some PHP users subscript to OOP ways and some do not. You can call it "inconsistency" but frankly I don't see it as such - I do not think language should necessarily allow only one paradigm and force everybody into a single way of doing everything.

>>> Functions which fail "silently" in the code but print a warning on a rendered page?

Printing a warning is a debugging feature, which is very useful when developing the code. Of course, production code, once not in debugging mode, should never do that - and never does. As far as I know, no functions fail "silently" - if they do not succeed, they produce some kind of error code or response. If some do not, it is a bug and should be fixed.

>>> After some time with Clojure, Python, F#, Erlang, and Go you'll be able to see PHP for what it is.

I appreciate your condescension, but in 20+ years in the industry I have had experience with many languages, from Lisp and Prolog to Python, and I can see PHP for exactly what it is - one among many instruments, imperfect but useful in suitable contexts.

>>> Just stop accepting everything it comes with as a "true way".

I can't stop doing something I never started doing. I completely reject the notion of "true way" existing - I think it is you that are approaching the discussion with a notion that you are going to open my eyes on other languages existing (which I knew and successfully used before PHP even came into being) or that PHP is inferior to them all because of some nitpicks that irritate you - which it is not, though it has its own deficiencies, and fixing and improving some of them is exactly what the article is about. It is continually saddens me that any development of PHP produces a predictable wave of hate and condescension, but I assume that is the price of being popular.