I don't understand how "mv", with relative and absolute pathnames, is implementation leakage.
I have been using UNIX-type operating systems almost exclusively for the whole of my professional life so have zero appreciation for the troubles people have when approaching UNIX tools from a Windows (or whatever) mindset.
Git (and the whole toolchain and OS for that matter) is much more about DWIS than DWIM and that does not click for a lot of people.
All of the established unix commands do a particular conceptual thing well. "sort" always sorts. Its options affect how it sorts.
But git ... "git checkout" can switch the working branch. "git checkout" can rollback code ... depending on the specified options.
For people with a mental model of files and directories built from using a GUI with windows and folders this does seem to be implementation leakage since you have to know that renaming is moving because of "how the filesystem works". They think of the file name as file metadata and the file contents as the file.
If you have a mental model built around unix-y file management then you probably think of the file path as the file and the fact that renaming and moving are the same thing seems obvious.
mv *.jpeg *.jpg
> REN [drive:][path]filename1 filename2.
> Note that you cannot specify a new drive or path for your destination file.
He would want "mv" to take 2 params: (1) old file path (e.g., "/users/dev/foo.clj", and (2) new directory (e.g., "/users/lib").
But yes, for this discussion, a higher level version would probably split it into two commands: rename and move. And these would only do those particular functions. With that there is no implementation leakage. For the few times that you'd want to move and rename, you'd need to use both commands.