At some version between coreutils 6.12 and 8.16, the option -n was introduced to cp. The ebuild uses it and fails because it's not present in the old version. While not strictly an issue since that coreutils version is no longer in the tree, I think one should be able to rely on fully functional binaries that are 4-5 years old when running a system upgrade. At any rate, the ebuild must explicitly require a version of coreutils that is more recent than the last version where -n was not an option. Otherwise, we get annoying hiccups in the emerge process that are fully avoidable.
NEWS: - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - * Noteworthy changes in release 7.1 (2009-02-21) [stable] ** New features [...] cp and mv accept a new option, --no-clobber (-n): silently refrain from overwriting any existing destination file - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - sys-apps/coreutils-7.1 went stable in April 2009, the previous stable being sys-apps/coreutils-6.12 which indeed went stable in April 2008. IIRC we have a policy of supporting upgrades from a system state that was current 1 (one) year ago. I am sure you understand setting version dependencies for changes introduced over half a decade ago would explode the portage tree and Gentoo's developers' workload beyond reasonable proportions.
