Semantic versioning is for APIs, not for functionality. So it's for developers consuming that API (whether a library, or a service).
For releases in production, use a calendar version. v2025-11-02 is a clear release tag. Add preciseness as required. There should be a SBOM/Manifest (Bill Of Materials) of the versioned major components and configuration for that overall release.
For users, it depends on the type of user and what they expect. Their focus is on functionality. So when there's a new feature, bump the number.
It's a bit like the car model. It can be random extension letters like "-X", or "6Si".
Oracle used to do that, didn't they?
So, amongst others, they had Oracle 8i at the height of the dot com boom (i for "Internet"), then a few years later when clustering became big news there was Oracle 10g (the g standing for "grid", I think?), and so on.
Actually, it looks like they might still be doing it - I just checked, and their current version is 23ai...
Developers are "users" (of a library, API, tool...), and "API functionality" is a subset of "functionality": what purpose would such distinction serve?
For example, in end user desktop software (say a text editor), how would you indicate a security bug fix for an old version v2023-11-02 without forcing users to pay for a new version of v2025-09-15?
Again, versioning is a tool, and depending on the release structure of a project, SemVer might work well or it might not (including for APIs/libraries).
Semver is semantic. It tells you about the changes in the API, not in the implementation. So it's relevant to the users (ie developers) of that API.
If I fix a bug in the implementation that doesn't affect the API itself, the semver doesn't change.
So it works to define the versioning of an interface.
Release versioning (like vyyyy-mm-dd) is about SRE and configuration management, it's about documenting what is actually operating in production.
User versioning is about user expectations. If you're doing a security bug fix, then a) it should be free to users affected, and b) it should be documented as the reason for the release.
For a security bug fix of v2023-11-02, you can add a "hotfix" extension to the numbering so v2023-11-02.001 or equivalent.
I can see how you are using the multiple versioning schemes to achieve certain goals, but that does not make your approach "one true way".
"Semantic" really means "has some background meaning", and SemVer meaning behind all the numbers is in no way limited to API versioning: I am confused if you are making a proposal to consider it only that, arguing that different schemes should be used for different types of software, or stating that this is the only thing SemVer can be used for?
On any of those points, I disagree and you haven't made a convincing argument why that would make sense.
Note that I am not saying that SemVer is the only true way to do versioning (very much not so) for all software, just that it depends on your release strategy what is most applicable, and not on the type of software you are shipping.
Versioning is a tool to communicate changes and backwards compatibility to the users. SemVer makes sense in a lot of cases, but it neither covers everything (eg. compare with Debian/Ubuntu packaging versions), nor is it always needed (think of REST API versions which usually only go with major versions, and commonly multiple major versions from the same codebase).
I always found semantic versioning a little too verbose. Particularly when deciding when to release major versions. OSX was on version 10 for many years but of course released a new "major" version every year.
Semantic versioning is just something everyone does in software development, but is is really that necessary?