> It's only useful to glean some general ideas or algorithms.

Sure, but they'll also have an easier time of ensuring they're "pretty close" to fully reproducing the original.

At least, in comparison to having to reverse something black box. :)

They're trying to be compliant to the interface of the original, not the implementation. Now whether the interface itself can be copyrighted ... the SCOTUS will weigh in on that soon (https://en.wikipedia.org/wiki/Google_LLC_v._Oracle_America,_...)

If the SCOTUS says yes, would the original GNU coreutils even retain their GPL license given that they reimplemented pre-existing, non-GPL utilities?

Not necessarily. The non-GPL utilities the GNU coreutils are based on are presumably licensed as MIT, ISC, Public Domain, or similar. If that is the case, those licensing regimes don't forbid adding extra restrictions, so adding the restrictions of GPL would be permitted, and the new derived (again, assuming interfaces are copyrightable) work would operate as being essentially GPL licensed. Things get murky as there are proprietary utilities too that coreutils are probably based on, but then there are also specifications of behavior (SUS, Posix) which might or might not sever the "derivation path" of the work, or might introduce further licensing constraints.

That case has no bearing on this because they aren't deciding if "interfaces can be copyrighted"

Do you view APIs as something other than an interface? A ruling from the Supreme Court may not reach the ultimate issue, but if it does, what assumptions would you make concerning the difference between an API and a program’s interface with the user?

An Application Programming Interface is ... an interface. As this very link points out, there are many programs that use coreutils via this interface.

Rust coreutils replacing GNU coreutils in these programs by implementing the same interface is the same issue.

I’m not sure if it’s possible to spell it out clearer than this.