I think I now have a solution for this: creating distinct repository name for each requirement line with extras. I'm not sure if this is the best solution though, because it leads to defining multiple, identical whl_library repositories even when different extras point to the same wheel file. This seems inefficient and unnecessary.

After looking around a bit, I realized that maybe following comment by @aignas would be a better solution?

I spend quite some time trying to wrap my head around the parse_requirements code and how to aggregate the extras. I could not figure out a way to make that work without breaking some other tests. I don't think I currently understand the requirement parsing stuff well enough to properly fix the underlying issue.

Creating another repo for foo[x] wouldn't be the thing to do, anyways. The extra doesn't affect the contents of the package (whl file downloaded). A repo is created for each unique (package, version) (i.e. one per unique artifact downloaded).

What the extra does is affect the Requires-Dist resolution later, when figuring out the list of dep targets. e.g. given foo[a] == 1.0, then the pypi_foo repo is created from the foo-whatever.whl file. A py_library(deps=...) is created based on the Requires-Dist entries in the wheel. Those entries can have conditions, like "only if extra X is requested".

Ignas would know this code better, but IIRC, the list of extras is kept and passed around somewhere so that evaluating the Requires-Dist lines has the right context.

This is a bit of a mess because historically the extra would result in a different set of deps wired in your closure. So in order to fix this there are two approaches:

1. Figure out how to aggregate the requirements without breaking existing tests, if there is no way, change the tests.
2. Enable pipstar by default (feat: enable pipstar by default #2949) - this would use starlark to parse the dependencies and we would not need to do this clever aggregation by extras anymore.

Just to outline the option number 2 (which is a better long term solution), the rough sketch is:

1. enable pipstar by default (I tried it briefly but it was not ready yet). It should be safe to do this in bzlmod and in theory it could even work in WORKSPACE with extra work on figuring out how the env_marker_setting can work.
2. to whl_library pass a list of extras for which we should create targets or create py_library targets for each extra found in the METADATA. The naming of the targets could be pkg for no extras, pkg__foo for extras==foo. If there is a dependency on pkg[bar] then we would need to translate that to a dependency on @<hub_name>//pkg:pkg__bar. If there is a dependency on pkg[bar,baz] then this translates to two dependencies - @<hub_name>//pkg:pkg__bar and @<hub_name>//pkg:pkg__baz. The naming convention of the targets is up for discussion.
3. to the hub_repository pass a list of extras for which we should generate extra aliases.
4. The parse_requirements code would only need to care about the extras and what need to be present where.

However, there could be still a need to fix the tests to make the behaviour more correct before we go the long way and implement option 2.