TYPO3 Core

First, you should not use "hardcoded" links in templates. Instead use proper
viewhelper which updates the correct page link after the slug has changed -
so not hitting the redirect anyway (directly).

For v11 you could disable the redirect auto creation and create custom
datahandler hook for it.

TYPO3 v12 introduced a handfull PSR-14 events around the auto redirect
creation where you can influence what kind/type of redirect is created
or create additional redirects beside the plain one.

The decision to make auto-redirect in a plain form is there since TYPO3
v9 and therefore we should not consider this as a bug and changing the
behaviour for all in a long standing LTS version.

And as already mentioned - you can adjust this for your instance using
events with TYPO3 v12 - and also doing quite more things.

For example:

https://docs.typo3.org/c/typo3/cms-core/main/en-us/Changelog/12.3/Feature-94499-ProvideAdditionalPageTypeSourceAuto-createRedirectSourceType.html
https://docs.typo3.org/c/typo3/cms-core/main/en-us/Changelog/12.3/Feature-99834-NewPSR-14ModifyAutoCreateRedirectRecordBeforePersistingEvent.html
https://docs.typo3.org/c/typo3/cms-core/main/en-us/Changelog/12.2/Feature-99746-NewPSR-14SlugRedirectChangeItemCreatedEvent.html

and other.

First, you should not use "hardcoded" links in templates. Instead use proper viewhelper which updates the correct page link after the slug has changed - so not hitting the redirect anyway (directly).

Where did i write, that i did that?

In our case we did just what you suggested - we utilized the f:uri.page ViewHelper. But because the generated URL is exactly the same as the redirect source path typo3 will send a redirect - even if its for no reason.

For v11 you could disable the redirect auto creation and create custom datahandler hook for it.

That advice is no solution to the bug - yes this is a bug.

TYPO3 v12 introduced a handfull PSR-14 events around the auto redirect creation where you can influence what kind/type of redirect is created or create additional redirects beside the plain one.

Neither would this be a solution because the behaviour should be correct using defaults only.

We don't deal with an edge case here, we don't deal with using "hardcoded links", we deal with typo3 behaving wrongly when using its very "core api features" exactly as they are documented.

I think it should be possible to reproduce this:

1) Create a page (lets assume it has uid 2) with the slug /test
2) Add any kind of typolink generation including some additionalParams (either use fluid, typoscript, whatever, the same link generation will kick in in the end
3) change the slug of the new page to /test2 (a redirect /test => t3://page?uid=2 will be added but GET paramters will be removed on redirect)
4) change the slug back to /test (a redirect /test2 => t3://page?uid=2 will be added like before)

At this point any correctly generated link, that points to /test will be redirected because redirect number 1 is still there. But all GET params will be removed for the location header.

The behaviour is clearly wrong.