I am pretty certain that fixing this will cost hundreds of dev hours within all the SF projects out there. That is part of the DX! Sometimes I would love to understand how much the framework wins by deprecating such a code path.

Anyway: finding all places in all templates and dynamically generated routes is a pain on its own, but an argument that I would like to offer are "bookmarks". I have seen it often, that routes and their parameter {id: 6} can be stored in the database. Updating those is way more complicated.

While the suggestion there is to remove the deprecation altogether, I think we'd better keep it so that we move people to a code that is always mapping explicit.

I agree that updating the docs to teach the correct way is great. But let me tell you about a developer who uses SF since years and who is been using {id} as a route parameter for all these years. Not because he had the idea himself.... I was simply following documentation examples and got used to it. And honestly, I have seen enough SF projects to know that I am not the only one dumb enough to fall for the docs.

Mapping by exact argument name is supported since the introduction of the entity-value-resolver so its very possible to upgrade existing code while still supporting previous versions of Symfony.

You know exactly that we have to adjust the code, it is not an option, but a mandatory requirement if we want to stay in the loop with upgrades.

OK, after talking with a few others on Slack, let's go to remove this deprecation.

I should be more on Slack I guess.

And sorry for being stubborn. Often I am not sure if I can transport my thoughts clearly.
In such a case I think "okay, I will work on this a few hours (including testing) on one project. I have at least 4 of these projects. And there are a multiple thousand Symfony devs out there. => Whoa, that is a lot of time that has to be invested."

Anyway: thanks for giving it another thought and for listening to everyones arguments 👍