I think fixing the underlying pty issue should certainly be the goal, but the question is whether the process group change should remain active in the meantime, as its presence is causing a regression in the tests.  I think such cases in the past are usually rolled back, right?

I was originally on the fence since process groups address a real problem, especially in interactive testing, while creating an arguably aesthetic issue for my case of the buildbots (a warning rather than failure).

But Pablo's point about a normal manual full test run failing (not a warning as with the buildbots) feels persuasive since that's probably as common as the issue being addressed by the change.  Even if pre-existing, the pty failure is exposed by the process group change, so it might be best for the process group change to wait on fixing the pty issue.

I don't know how to weigh the relative impact though, e.g,. how many people are likely to run into each failure case.  There's probably more people doing a normal test run than breaking out of such tests though.  At the least, it's a worst impact than just the warnings on the buildbots.

Perhaps an intermediate fallback could be gating the process group change behind a regrtest option (opt-in) which could then preserve its benefits upon request, without negatively impacting the default test process, whether manual or on the buildbots.

At least until resource is available to resolve the pty issue.