What do your Scaled Trunk-Based CICD Pipelines look like?

Hi, I'm curious how teams are supporting a Scaled Trunk Based model with their CICD, what they are automating, what they are not, etc.

We use CircleCI, we have a Test, Beta (pre-Prod), and Prod environment. Our short-lived feature branches are built, unit tested, sonar-scanned. Once merged to trunk they are deployed to Test, and system tests/acceptance tests are run.

To get to Beta, a release branch is opened, and it basically does the Test process, then deploys to Beta, runs the Beta system tests, and waits for approval to deploy to Prod.

We don't really leverage tags, or do a great job of tying deployments back to source control (Github). I'd like to do that but then questions start to arise in:

• When exactly do we tag? Beta deployment, Production deployment?
• What if there are accidentally two release branches open at once? Would that mess up the tags?
• What type of tagging to use? Semantic versioning, just a datetime stamp, etc?
• On the release branch, should we skip the test env? Deploying there will potentially overwrite the trunk deployment there. This is probably up to us, but I'm not sure it's worth re-deploying there.

All in all, it just seems like a common paradigm, but I don't see many examples/templates/best practices out there to support it. And, I just want to get off on the right foot if possible and avoid dumb mistakes. Or, just hear about clever solutions that engineers like working with. Thanks!

p.s. I understand this is not pure trunk-based. Hence the scaled variant. We have a few development and process practices to iron out before fully committing to pure trunk-based.