Nit: I think we'll have quite a few started and cancelled builds, where a tag is pushed just after a merge.

Nit: I think we'll have quite a few started and cancelled builds, where a tag is pushed just after a merge.

We do not have any concurrency settings, so by default, all workflow runs run concurrently.

How do we fetch tags (is it git fetch --force --tags) during the build process? I don't want the latest pushed tag to an older commit to somehow exclude all later tags from the latest commit.

Without proper concurrency settings, module tags pushed to older commits can cause build issues:

A --- B --- C --- D  ← Main branch 
      ↑     ↑     ↑
      |     |     |
module-a/v1.0.21  module-b/v1.2.0
            |
            ↓
      module-a/v1.1.0
      (pushed later to an older commit)

Would this new tag (module-a/v1.1.0) pushed to an older commit cause the newer commit tag (module-b/v1.2.0) to be excluded from the latest build?

No there wouldn't be any issues here. The release tag just says "the source for version vX.Y.Z of this module comes from this commit". It is completely valid for an older commit to be used as the source of truth for a newer version of a module.
There shouldn't be concurrency issues with fetching tags or anything either. The entire repo is cloned and all tags are present for every build.