In addition to its two unrelated senses, there's a better-known confusion of meaning about "functional": some people prefer to call a program, or a language, "functional" only when it's purely functional - no state. I, like most functional programmers, think this is excessive - mutation is not so toxic that a little bit condemns whole programs! But the moderate view is a little hard to defend.
You might call a language "functional" if it supports the style (either one) reasonably well - but that can be awkwardly inclusive. (Do you really think of Perl as a functional language?) You could restrict it to languages that support nothing else - but that excludes the most common, and useful, functional languages, for the very thing that makes them useful: their flexibility.
In practice people classify languages by the style they support best, or by how they are commonly used. This is not a theoretically sound test - it has the perverse effect that improving a language's support for other styles makes it count as less functional, even though its ability to express functional code hasn't changed. But it does predict what sort of code you're likely to encounter in the language, which is useful enough to outweigh its impurity.
By the way, could we stop insisting that "pure" always means "pure functional"? It is useful to be able to talk about any unmixed style. Prolog is (almost) a pure logic language; most machine languages are purely imperative; Self is purely object-oriented. There are many ways to write programs, and it does the programming-languages community no favor to declare that one of them is "pure" and the rest, however undiluted, are dirty.