How is GA determining if it should store its data as cookies or push it to url?

Pushing the data to url is the mechanism of cross-domain tracking. You set a list of domains that cross-domain tracking should work for. This is likely your problem here. You’re not supposed to set subdomains, only TLDs in vast majority of cases.

Where are these parameters stored before user redirect first time? Is it part of datalayer / google_tag_manager global variables?

This data is stored in cookies before the user goes to a different domain. If cookies are deleted, then it’s stored in the JS scope of the GA library. This implies that they would be erased and regenerated on JS context loss. Loss on a page unload, regeneration on a page load.

Is there way to store the params somewhere else than in url when full cookie consent is not granted?

Well. Yes. But very tricky and expensive. And the immediate question is why would you do that. This would defeat the purpose of blocking the cookie. Natively, GA doesn’t support other methods of passing the value, but if you’re into tinkering, you can either store the value on your backend and then retrieve it, using some “primary functionality” cookie. Another option is using third party server’s cookies, but that would defeat the purpose even more.

Is adding of GA params to url even when staying withing same domain a correct behavior?

No, it’s most likely a mistake.

Now, you really asked all the right questions, so I don’t have much to add, except that disabling your primary anonymized behavioral tracking is usually a lazy “safe” choice. And lazy here implies wrong.

Normally, larger corps don’t block primary tracking. They only block third party marketing-related tracking. Basically, pixels. They consider their main analytics part of the primary functionality, which is a strong case given that main analytics data is often used in debugging, performance measurement and even for app security audits.

Finally, using onetrust or a similar solution to completely manage your tracking is sub optimal. They basically just destroy all “offending” cookies all the time. This will mess up your behavioral data very significantly.

The proper way to use consent management systems is declaring user consent choice in your tag management system and then in it, block rules/tags from firing in case the consent is not given. You normally just carefully block marketing tags there based on consent. Remember, consent management systems are only deleting cookies. Because that’s trivial. They don’t block network requests. Absence of cookies may not prevent the data from being sent, often even uniquely identifying the client, using the primary cookie’s user id, allowing to match the activity to the backend database.