It’s actually kind of wild the sheer breadth of use cases that the current tooling is expected to handle, and I’m not sure that any one person even knows all of them. Trying to enumerate them all would be a pretty huge undertaking but if someone were to do that, would be pretty useful I think.
I’ve had a number of ideas for “simple” fixes to even small corners of packaging over time, and I think almost all of them, once I started to explore actually doing them, ended up producing several thousand words just to fully express the idea and factor in various workflows that people are using that seem generally reasonable.
I’m probably someone that gets viewed as “shutting down” conversation since I think I do often push back against “simple” ideas and try to expand into why those things aren’t workable without a lot more thought being put into them. Speaking for myself, I don’t actually mind that kind of discussion. I think it’s one of the best ways we have of doing knowledge transfer in this area right now, and if someone feels strongly enough about a suggestion, I hope they continue to push for it and try to come up with mitigations for the concerns, evidence that the concerns are overblown, or justifications that the change is worth the cost anyways.
I think this back and forth ultimately ends up making for better solutions to these problems as well. I think an interesting “demo” of this working in practice is these recent threads on dependency confusion. Where you can see “simple” ideas get thrown around, push back against them for not solving X, Y, Z use cases, and then refinement to the ideas until the idea got forged into something that was no longer quite as simple, but that actually handles most of the use cases. In participating in that discussion, I even personally ended up finding new use cases for our tooling that I didn’t even realize people were doing.