No arguing that working on setuptool to improve it would have been better but the thing is that Phillip (setuptool) hasn't been cooperative (to say the least) a

No arguing that working on setuptool to improve it would have been better but the thing is that Phillip (setuptool) hasn't been cooperative (to say the least) and Tarek ended up forking. At least that's how I remember it, so in that light, everything on your article is true but setuptool had to be "rebooted" as pip. I think that pip + distribute intended to be a pragmatic approach you're calling for and that distutil2 is the cleanup/rewrite/redesign you said should happen after. Except it's not as clean cut as "repair setuptools with as much hacks as necessary and then rewrite the implementation once all design decisions have been finalized". That said, you're completely right, use cases were forgotten and distutils2 might have started too soon. Hopefully your article sparks interest in those others use cases.