Given I have a product which follows SemVer versioning approach. Given I have several customers which receive builds of my product. Given 2 customers at once are asking me to make a hotfix to their version 1.2.3
How should I version the two patches?
I.e. I have shipped 1.2.3 to customer A and customer B. Both say they need a patch urgently. And the patches are different.
The only solution I see is to add some modification to SemVer and add customer specific suffix:
1.2.4 A and 1.2.4 B and afterwards release 1.2.4 as a main version if needed with both fixes.
Any better options?
Based on available information I cannot give you a definitive answer to your question, but here's some things to consider carefully before proceeding:
If at all possible, find a way to make both changes coexist. This will avoid forking your product base. One technique is to make the patch changes configurable via command line or config file.
If both patches cannot coexist in the same release, then you are essentially forking your product. Changing the package and product name is probably the best solution. Since each of your customers is asking for something special from you, they should not mind if they have to change their dependencies to use the new product. So if your product is named Px supply PxC1 and PxC2 to each of your special customers and begin versioning them separate from Px.
Using prerelease tags can be a suitable temporary solution, but it will lead to complications as your product evolves. Unless these are your only two customers, you wind up with at least three forks of your product and no easy way of distinguishing between the two, other than knowing which specific patch number to take. This makes automation difficult at best.
You should consider whether different versions of your product might be included into a dependency tree by way of third parties. If any of your customers include your package in something they redistribute to other customers, chaos will ensue eventually. This is especially true if the two special versions cannot peacefully coexist in a side by side execution environment (shared external resources for instance).
Addendum: I should mention that you might be tempted to use the build meta tag to visually distinguish the various forks, but not all packaging tool preserve the tag and most don't provide a graceful means to use it for selecting the correct package version.