I'm looking to fork a project and merge one commit that is currently still open but that would be incredibly beneficial for my means. The commit serves to fix a previous build system bug.
I'm unsure if, according to semantic versioning, that additional commit would represent a patch increment or as build metadata or some other convention.
If the former, I would imagine the version number would, for example, thus be v"1.2.1" wherein the patch version is incremented, or, in the case of the latter, be v"1.2+commit hash here".
Your repo already tracks revisions via content hashes (commit Id's). SemVer is not relevant for source check-ins. It should only be applied to published artifacts. Consider using some form of semantic commits, where the commit message includes standardized information regarding the type of changes made, that the build system can use to determine the appropriate version bump when it produces a package.
Changes to build scripts or tooling require a minimum of patch level bump.
Build metadata is generally ignored for package sorting/selection and is often stripped by packaging tools/feed services. It is not a prerelease, so if you only embed the change information in the meta tag, you could potentially have two packages with different content, due to changed build environment, and the same effective version numbers (BAD).