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).