This topic was discussed extensively during the original review. With respect, characterizing the design as flying "in the face of everything Swift API design", or appealing to "a decade of precedent," as another commenter put it in the original review thread, is not a technical argument; it is an appeal to convention. I understand this API design broke some of those conventions, but we gave technical reasons of why we made that concious deicison.
I also want to push back on the comparison to print(). As we covered in the original review thread, a free-standing function in a package is fundamentally different from one in the standard library. You do not get run() automatically. You must explicitly write import Subprocess, which clearly communicates intent. Moreover, you can already qualify the call as Subprocess.run() if you prefer. I recognize the general concern about namespace pollution, but no one has yet demonstrated a concrete case where this design creates an actual ambiguity that cannot be trivially resolved during the beta testing period.
I understand and agree with the concern about testability. However, I do not believe it is Subprocess's responsibility to solve that problem. Subprocess has a single, well-scoped job: providing the primitives needed to spawn child processes. It is the client's responsibility to wrap those primitives in whatever abstraction they see fit, asuch as protocol, wrapper type, etc., that suits their testing strategy. This is no different from how consumers of FileManager routinely introduce their own protocol for testing purposes; we would not expect FileManager itself to be a protocol just to accommodate that pattern.
"Unfounded" implies the design decisions were made arbitrarily, which is not the case. We provided clear, documented reasoning for each choice during the review. I remain open to reconsidering, but that requires a concrete technical argument against the reasoning we already laid out — not a restatement of the conclusion that the design does not fit convention.