[lprnmns]

The pyproject.toml specification says, for [project.entry-points]:

Build back-ends MUST raise an error if the metadata defines a [project.entry-points.console_scripts] or [project.entry-points.gui_scripts] table, as they would be ambiguous in the face of [project.scripts] and [project.gui-scripts], respectively.

StandardMetadata.from_pyproject() currently accepts both groups and returns them in entrypoints:

[project]
name = "test"
version = "0.1.0"
[project.entry-points.console_scripts]
test = "test:main"

StandardMetadata.from_pyproject(pyproject).entrypoints
# {'console_scripts': {'test': 'test:main'}}

A back-end that follows the module docstring example (ep = metadata.entrypoints.copy(); ep["console_scripts"] = metadata.scripts) then silently drops these entry points. flit_core already rejects them ("Scripts should be specified in [project.scripts] or [project.gui-scripts]…").

This adds the check to the existing project.entry-points key validator, next to the group name check. Each of the two groups produces a ConfigurationError that points to project.scripts / project.gui-scripts, and is collected like the other errors when all_errors=True.

Three existing tests used console_scripts only as an example group name, for a type error and for the PEP 808 dual-dynamic case. I renamed it to some_group there, since those tests are about other behavior.

Tests: two new test_load cases ("console_scripts in entry-points", "gui_scripts in entry-points") fail without the change. The full suite passes (410 passed, 115 skipped), as do ruff check and ruff format --check. mypy reports the same four import-related errors in the test files as on main in my environment.