Trunk-based development release & hotfix questions

I'm having trouble to understand how to deal with the following scenario:

1. Feature A is committed to master as commit A.
2. We are ready for release v1.0.0 so we tag commit A as v1.0.0 and we create a release branch rel-1.0.x from it for QA.
3. Feature B is committed to master as commit B.
4. QA approves v1.0.0, we deploy and delete the rel-1.0.x branch.
5. We are ready for release v2.0.0 so we tag commit B as v2.0.0 and create a rel-2.0.x branch from it for QA.
6. A bug is found in production (v1.0.0) and must be fixed and deployed right away.

At this point I'm not sure how we should handle that. If the bug is in the trunk we could create a hotfix branch from the trunk, fix the bug and merge into the trunk. Then, create a rel-1.0.1 branch from v1.0.0, cherry-pick the fix from the trunk, tag it as v1.0.1 and deploy.

Now what I find odd is that the v1.0.1 commit is not as-is in master given it's been cherry-picked from master and tagged in the rel-1.0.1 branch. Furthermore, if the fix is also needed in rel-2.0.x then how should we handle this? Should we cherry-pick the bug-fix from the trunk again and tag it as a different version, such as v2.0.1?

Here's the kind of graph I'd be getting doing the above (note that v1.1 represents version 2.0 of the text above and that it's the Second feature A fix that occurred while preparing the v1.1 release.):

Coming back to this question, it seems like my concerns were not founded and the versioning/tagging approach as well as the workflow described in the above question is acceptable and works just fine in practice.

One challenge I've faced though is when master incrementally diverges more and more from what's in production. This could happen for many reasons, such as having commits in master that were in theory ready to get released, but somehow didn't go in production. The way I've dealt with that problem is by continuously re-working the commit tree in production so that what diverges stays on top.