Is this a good process for doing releases?

Ever since moving to Azure DevOps; we've followed this same release process for almost all our projects (we run about 15 different projects/repos). Using trunk-based development. But something feels off sometimes, and I'm wondering if we're doing something wrong.

1. Dev makes branch off of master to do work
2. Dev makes changes, 1 or sometimes more commits, pushes and creates PR to merge into master.
3. PR is reviewed and approved, merged into master, triggers a build to send master to test.

This happens for several different tickets. At some point, based on schedules, client needs, and priorities, project manager says that everything in test is good to go for the next release.

1. Release branch is created off of master.
2. This release branch is built to Stage environment.
3. Things are re-tested in Stage (not as details testing, more high level to make sure the deployment did what we wanted).
4. Same branch (even the same build artifact) is released to production.

This generally works, but results in a few different annoyances/problems:

• If something needs to go to prod before other things that are already in test (a hot fix), we need to cherry pick into a new release branch made off of the current production release branch.
• It can be hard to know what exactly is new in a release. Generally it means comparing the new release branch to the last one, but then you just have a giant list of commits (and any cherry picking that happened seems to mess with this, where a cherry picked change will still show up in the commit diff even though it is in both branches).
• We sometimes have to hold off merging things into master (keeping the PR open) just to be able to finish testing everything in Test; we can't add anything new until the release branch has been cut.
• If all but 1 thing is good in Test and signed off on, but that 1 thing requires us to wait, then everything has to wait.
• I keep seeing examples of setting up pipelines where the same pipeline has multiple stages for test->stage->prod (or often dev->test->prod instead). This isn't possible when master is what goes to test, but a release branch is what goes to stage+prod. We do use multiple stages in a single pipeline to release to stage then prod.

Outside of completely abandoning trunk-based development, can this process be improved? How do others do release management for trunk-based development?