Any path that starts with
/ is an absolute path, not relative.
If all paths were always relative to the current directory, how would you
cd /etc in the first place? You'd have to
cd ../../../../../etc and hope that was enough levels of
.., or just keep doing
cd .. until you got to the root directory.
Or you'd need some other syntax to express absolute paths. But Unix decided on
/ meaning absolute, anything else being relative to the process's current working directory. So
mv MyFile.txt openvpn would work.
And no, it wouldn't work well to infer absolute vs. relative from files existing or not. We wouldn't want
mkdir system calls to treat paths differently from
rename system calls, and making the
mv program do it just leaves room for inconsistency between
mv and some other program that takes an output filename.
mv is already special because when the
rename() destination is a directory, it appends the source filename to that destination directory and tries again. But notice that one simple implementation strategy relies of the first
rename() system call failing with
EISDIR. So we have to know whether a path is relative or absolute before checking the filesystem.
(Early Unix ran on slow computers, where extra checks if a directory existed could mean extra I/O if it wasn't cached, or more pressure on directory caching. But I think sanity / correctness arguments are sufficient to explain why your first guess wasn't a plausible way for the system to work, without resorting to historical efficiency arguments.)