bug#18748: cp doesn't behaves as mkdir and touch when a default acl exists.

[f0rhum]

Hi gnu world
I posted a monologue about this in the list
http://debbugs.gnu.org/cgi/bugreport.cgi?bug=8527.
Another got more audience:
http://lists.nongnu.org/archive/html/acl-devel/2014-10/msg00001.html
Well I read the coreutils FAQ and other the rtfm link, and I think it's
time to ask if we could have a question for this in the coreutils FAQ,
with the same brillant style than the ones for
http://www.gnu.org/software/coreutils/faq/coreutils-faq.html#Why-doesn_0027t-rm-_002dr-_002a_002epattern-recurse-like-it-should_003f
and
http://www.gnu.org/software/coreutils/faq/coreutils-faq.html#Why-don_0027t-the-utilities-have-built-in-directory-recursion_003f
, both refering to Unix philosophy, and both great light for
half-gnubies like me.
This one could be called "Why don't we have automatic inheritance of
permissions with default extented acl?"
This is a too long title, but too short to paint the landscape.
I know acl definition in the POSIX 1e draft 17 is a withdraw job.
I know acl is neither in coreutils nor even in GNU. I also now that the
N in GNU stands for "not", so why "not" adopt the job further like yet
cool working mkdir and touch? These two were made compliant with default
extended acls, so why not cp and mv?
I also know sgid is a step on the path of inheritance, but not enough
when another group is needed.
I think (maybe I think bad) that cp and mv, at least on local, when run
__without-any-option-directly-related-to-the-permissions-mode-bits__ and
then meet a default acl set at the destination directory, would discard
they traditionnal behavior (that is re-writing permissions according to
umasked process and/or mount ones, not sure) and instead would rewrite
according only the said default acl as long as the process already has
the write permission. Gureeks are there to mitigate my imagination ;-)
Michael Orlitzky (aka copyright sucks) already did such a job, so why
not make room for him? (or maybe it's already a WIP?)
At least the FAQ would explain why 2 groups is one too much, both in
Unix and GNU philosophies.

Thank you

Fabrice