Of course copyright and patents are different beasts, so this similarity is probably legally insignificant.

To me, it seems obvious that if the developer read the code that's getting replaced and reproduced its behavior to the T, by reading it and running it many times... that's the opposite of a clean room implementation. What do you think a dirty room implementation is then?

I'm not saying you are right or wrong, I'm not an IP attorney and I think IP is really boring. I can see how if a developer at a giant company rewrites open source X in Swift, C# or Golang in order to exploit it commercially, there could be a cathedral of opinions that would support, "Okay, this is what is meant by clean room." In the same way that BigCo developers work with their attorneys to file patents for ideas they saw elsewhere and didn't invent all the time. It's one of many possible beliefs about IP, and it can even thrive in reality, but it doesn't mean it is a correct one.

However I'm unaware of case law indicating that it's strictly necessary. If the final implementation differs enough from the original, no copyright infringement occurs and no one is going to sue anyone, so the steps taken to arrive at the new version are less relevant.

> Typically, a clean-room design is done by having someone examine the system to be reimplemented and having this person write a specification. This specification is then reviewed by a lawyer to ensure that no copyrighted material is included. The specification is then implemented by a team with no connection to the original examiners.

Without the disconnection between examiners and implementers, it's only slightly similar to a clean room. And we have new case law to consider: an API may be subject to copyright, and those unit tests are highly suspect under that lens.