Summary
When consuming a dependency whose POM contains a self-referential URL like:

<url>${project.url}</url>

Maven 4 fails model building with error "recursive variable reference: project.url". With Maven 3, this did not cause a fatal failure; dependency resolution proceeded (the POM was considered usable, possibly with a warning) and transitive deps were available.

Impact
Real-world artifacts published with such POMs (e.g., com.slack.api:slack-api-client:1.45.4) become unusable as dependencies under Maven 4.

Reproduction

• Create a local repo with a POM containing ${project.url}.
• Use that artifact as a dependency in a test project.
• Run mvn -X validate with Maven 4: it fails with "recursive variable reference: project.url" while building the dependency’s model.

Expected (Maven 3 behavior)

• Model building should not fail fatally on this specific self-reference. Dependency resolution should continue, possibly logging a warning and leaving the URL as-is or otherwise handling it leniently, as Maven 3 effectively did.

Proposed next steps

• Add a focused IT that installs a dependency POM with ${project.url} and asserts current Maven 4 fails (documenting the regression).
• Then investigate Maven 3’s interpolator/recursion handling and adjust Maven 4 to preserve compatibility (ensure dependency model building is lenient for the URL fields).

Notes

• Problem triggered in DefaultModelInterpolator/DefaultInterpolator interaction.
• The invalid descriptor path surfaces via DefaultArtifactDescriptorReader when ModelBuilder raises an ERROR (not WARNING).

I can submit a PR with the failing IT to anchor the discussion and help drive the fix.