First, you did not identify the original dichotomy between functional programming and imperative programming, and did not relate why the dichotomy came about. I think you don’t understand why, and assert that understanding why is critical to understanding how the terms are commonly defined.

On this matter, I’ll quote perhaps the most widely respected book on programming aesthetics, Michael Scott’s Programming Language Pragmatics: “The many existing languages can be classified into families based on their model of computation. [...] The top-level division distinguishes between the declarative languages, in which focus is on what to do, and the imperative languages, in which focus is on how the computer should do it. Declarative languages are in some sense ‘higher level’; they are more in tune with the programmer’s point of view, and less in tune with the implementor’s point of view” (Page 5). In a so-called high-level language, the programmer’s view-point and the implementor’s view-point will never be exactly the same. However, imperative languages provide strong hints about how to do something.

In truth, it is a mistake to call languages with an object-oriented model imperative and it is a mistake to believe Wikipedia when it says functional programming is in contrast to imperative programming. To illustrate my point with a trivial example, the object-oriented model generally supports reflection, which is neither declarative or imperative but instead interrogative.

However, it is also incorrect to say that imperative programming is a division of functional programming. Why would you want to compartmentalize functional programming in this way? What value does it bring other than familiarity which is always subject to opinion? Changing ontologies here does not seem beneficial to the programmer or implementor. In fact, it is just as frantic a categorization as the original ontology. I would rather model my problems at a higher level of abstraction. As Christopher Strachey once said: figure out what you want to say before you figure out how to say it. What you want to say will generally need to include some mix of knowledge to form a cohesive picture of the problem application domain. If you are building a tool that sits atop a language or some API for that language, then interrogation is quite useful.

Come to that, I have something to say about this quote: “In the relatively rare (though inevitable) case of performing I/O, only then will I resort to the imperative programming technique within pure functional programming.” My intuition says that you should resort to describing the part of your problem that requires imperative knowledge with imperative programming. I/O happens to fit this case well, and it is also an area of programming that succeeds well with programming-by-contract when it comes to writing portable code.