I don't think you read my comment properly. I'm saying that the security feature doesn't apply to Docker, but disabling it would be bad because it will affect other applications on the system.
> The preferred suggested fix was "mknod and chmod during image builds to be executed from outside of any chroot".
Which as I said, wouldn't be a good idea because of how chrootarchive works. In short it would lead to path traversal attacks, as with the issue you mentioned. The fix was to properly chroot things IIRC.
> A more intelligent fix would be 'require a modern/secure archive extraction tool'.
I agree. Are you willing to write a patch for it (or add patches to GNU tar?), because I'm afraid I don't have the time to do it at the moment (and I don't contribute to Docker that much these days).
> The second fallback was [...]
Which would be a bad thing to do because it would purposely disable security features that will affect other applications.
This in a nutshell is why the incompatibility is significant: systems may be running more than just a docker workload requiring these security features, so saying "it's secured in the normal docker case anyway", even if true, doesn't really help to solve the problem.
The preferred suggested fix was "mknod and chmod during image builds to be executed from outside of any chroot". In siding with docker in not considering this fix, you seem to be alluding to last year's http://seclists.org/fulldisclosure/2016/Oct/96 vulnerability, now fixed. A more intelligent fix would be 'require a modern/secure archive extraction tool'.
The second fallback was "Docker could check for the existence of /proc/sys/kernel/grsecurity/chroot_deny_chmod and /proc/sys/kernel/grsecurity/chroot_deny_mknod and, if present, ensure the values of both are 0."
AFAIK nothing happened.