Section on entrypoint extras could use clarification

the extras field related part of the entrypoints data model description currently states:

Using extras for an entry point is no longer recommended. Consumers should support parsing them from existing distributions, but may then ignore them. New publishing tools need not support specifying extras. The functionality of handling extras was tied to setuptools’ model of managing ‘egg’ packages, but newer tools such as pip and virtualenv use a different model.

a text-related question would thus be: what is that 'different model'.

my practical question is: how should i implement modules that contain entrypoints that are supposed to be only loaded when a certain extra (dependency) has bee installed upon installation? afaict, pkg_resources.Distribution.extras contains all defined extras from the metadata, not just the installed ones. so for now i can only think of designing a module that contains entrypoints like this:

# the example assumes a console_script was defined w/o tying it to an extra as recommended
# the requests module was only installed when a certain extra (for dependencies) was selected

try:
    import requests 
except ImportError:
    def my_console_script():
        raise RuntimeError("Though I'm available, I can't help you due to a missing dependency.")
else:
    def my_console_script():
        pass  # functional code here

please note that i'm not a native tongue english speaker and might miss some subtleties.

Start with the extras section in the linked entry points data model description and review the issue's references to setuptools, pip, virtualenv, and pkg_resources.Distribution.extras. Clarify what the newer model means and explain how entry points tied to optional dependencies should be handled, including whether the current wording needs revision.