The point where the SCM interpretation of dependency is most likely to feel strange is the restriction to bind it to a derived object. In the common understanding, such considerations are irrelevant, and one may very naturally think at having "dependency" relationships between separately maintained items, such as e.g. a requirement specification and an implementation. Let's consider the archetypical case of a C source file "depending" upon a header file.
The relationship is expressed in a specific way (typically through an "include" directive, processed by the C preprocessor, as part of the compilation). I.e. to be interpreted, a certain tool has to be used, which is not explicitly named in either of the two items. Note that other syntaxes may allow to express similar relationships, e.g. html hyperlinks may be followed by indexing robots. Some syntaxes do not offer such functionalities.
We can thus say that this relationship can be interpreted as a dependency under specific conditions. With this wording, the terminological conflict is resolved: the SCM dependency is the recording of the interpretation process. The result is generic, i.e. can be processed in the same way, whatever the initial syntax or tool was. It requires however a suitable "derived object": one may need to create one, even as a dummy place holder.