This distinction is often considered as universal. This is an error. Any meaning it may have is as usual context dependent. As an attempt to analyse further the issue, I suggest three kinds of contexts: one binding to the notion of module, the other to the problematic of representation; the last one investigates the dichotomy between physical and logical interfaces (low and high level?).
A module has an interface and an implementation, and may be used by entities knowing only its interface.
Interfaces must be static in order to support strong modularity and incremental construction. This way, and only this way, the results attained so far are not put in jeopardy by later work.
The header file / source file distinction is relevant to the compiler.
Many software components (programs, dynamic loadable libraries, device drivers, ...) are actually interfaces towards other systems. There are thus various levels of interface/implementations, or to put it differently, the interface/implementation distinction is an analysis pattern that may be applied to the description of many levels inside a system. It is not a global notion.
The more general problematic here, is this of representation of something existing otherwise. It relates again to the perception / interpretation dichotomy, or to the existence / essence one.
Note that during the maintenance phase, the software (product) becomes the actual focus of scrutinity: it is not anymore the "implementation" of an external specification (that would be its "truth", its meaning...).
One needs in any case a syntactic element (an artifact) to be used as a support for the logical interfaces. The expressivity of this element is likely to limit the actual choice of the interfaces.
There is an intrinsic structure in the artifact: it may restrict the expressive power of the mapping. Semantics are "flatten" if orthogonal (independent) features are represented by the same means (e.g. prefixes in variable names, to support some grouping). The contrary is possible too: the same semantics may be supported by orthogonal dimensions of the artifact, leading to arbitrary discontinuities (e.g. classes and tasks in Ada).
If one uses Unix sockets, one can only support very limited kinds of interfaces. The same is true if one chooses IDL descriptions or Java interfaces: there will be no behavioral part in the logical interfaces.