zipp can be dropped too

I'm not sure zipp can be dropped. It's true that stdlib provides zipfile.Path, but there are features and behaviors added to zipp since, and this project still relies on zipp for newer Pythons. This choice was intentional, for importlib_metadata to provide the most recent behavior available, including zipp releases. Even if zipp hasn't changed since {current oldest supported CPython}, if any improvements/changes are introduced in zipp, those should be made available to importlib_metadata. At the very least, we can't drop use of zipp as a simple compatibility shim. We could consider dropping use of the shim, but that would require more deliberation and a backward-incompatible release.

The reason importlib_resources is different is because it was explicitly pinned to stdlib on Python 3.9+ (this project already made the decision to rely on importlib_resources from stdlib.

I'll revert the head commit so we can proceed with the original proposal. Feel free to file a separate issue if you wish to propose dropping the dependency on zipp (and present an argument for that approach in light of above).