bug#5926: feature request: mv -p to create missing target dir

[f0rhum]

> The mv command causes an atomic rename(2) to occur if on the same file
> system.  That is not possible when using cp + rm.  Therefore mv is
> required.
Hi Bob.
I am just trying to understand why this very request is refused with
the argument "small is beautiful", when the "-p" was accepted for cp:
I mean why wasn't refused "cp -p" request, saying "just use mkdir first".
This seems unfair for mv to be refused the ease of use cp was offered.
Maybe I have a problem with understanding this "atomic" word
which also stunned myself in iptables documentation. 

> If mv'ing a file from one file system to another it is impossible to
> have an atomic rename().  In that case mv falls back to effectively cp
> plus rm.  That is mentioned in the mv documentation.
The same "You have to know if the parent exists" argument that was opposed
to this request could have also been opposed: "You have to know if you are
moving in the same file system or an other,
so we stick to rename+cp+rm, no need for mv at all, small is beautiful,
do one thing and do it well".

That's not to argue. Just coming to GNU since 6 years from closed source
OSes where nobody wouldn't even have the idea to ask why this-and-that, I
realize here I can ask why, e.g. why we haven't some kind of uniformity in
commands parameters --long and -short for various commands. This would be
a great help for average users. Somebody once replied to me "it is because
many different people work(ed) on these commands, at different time...". Just
a pure fact we have to live with. Is it the same inside the coreutils 
team too?

Bye bye

Fabrice