There are known performance concerns. I recommend to set those aside for now or move them to a separate issue because

(a) The performance is theoretically better in the nominal case because it avoids a sort/group operation.
(b) There are known performance degradations introduced by importlib_metadata 3.5 to de-duplicate distributions, degradations mitigated somewhat by importlib_metadata 4.3.
(c) Compatibility layers may be confounding performance concerns.

May I suggest addressing performance concerns in the importlib_metadata project as that project provides much better granularity on the different changes?

> I think my only satisfactory outcome would be:
> - the original api returns actual dicts

The original API returns an actual dict subclass (SelectableGroups).

- the sub-api returns actual lists

With https://github.com/python/importlib_metadata/pull/323, this expectation is also met as EntryPoints is a list.

- the new select is implemented as a separate *new* api without changing the existing api

The new API is invoked only through opt-in calls not previously available in the old API. I believe this achieves your goal without requiring a new name for `entry_points` or `Distribution.entry_points` (and thus creating less toil for consumers).