This actually hit my previous company in a software context.

We would number hotfixes sequentially. Customers would be notified when hotfixes were to be deployed to their sites. One savvy client noticed the hotfix numbering sequence and worked out both that we had a lot of hotfixes (tens per week) and that they didn't get them all right away (if you don't ask for it, it comes to you in the next quarterly trunk release.) Many awkward discussions ensued.

Solution: new policy to number hotfixes randomly instead of sequentially. Whoops, now sometimes hotfixes that had dependencies would get deployed in the wrong order.

Solution: also name hotfixes by date. Whoops, now the client can figure out that two weeks elapsed before they got the hotfix. (For all your usual enterprisey red-tapey risk-aversey reasons.)

The canonical solution that the Wiki suggests (which seems like a fairly good idea to me) is to make your "serial" number an encryption of the actual serial number; that way your tooling can still get the real ordering, but customers will find it computationally hard to get that information.

Why not add random increments to the sequence? This way order is preserved, but you never know how many hotfixes are between hotfix X and Y. Of course, you can still have rough estimate (as between #1000 and #2000 there is from 999 to 10 hotfixes) but for your case it may be enough.

Precisely.

Just because there private hotfixes that deliver custom tweaks to specific customers. in fact, that's exactly how Microsoft has had it set up for years.

Why is it an issue for alerting about hotfixes? Wouldn't it make sense to get fixes out sooner rather than later? Or maybe I'm missing something here.

There may be a decision making process on the client's side about whether to accept the new hotfix, maybe they have a workaround for the broken functionality or maybe it's just not worth the risk to them.

Then you might create another hotfix while that decision making process is going on, and both you and the client need to evaluate whether it's possible and desirable to apply the first one, second one, or both.

It's why versioning, source control, build process automation, and client communication are so important to get right from the outset.

The solution should have been to append a random string to the hotfix number. Still sorts the same way, but unguessable.

That doesn't help anything. You can't guess the next hotfix number, but you can still tell what order they were in and, after seeing a few examples to figure out how long the non-random part is, tell how many were skipped.