Issue IDs

I think the average large org has a much more straightforward posture here: They have a single central repository (which might or might not be a DVCS like Git), and whatever identifier that centralized repo assigns is the identifier you use for everything.

Edge cases:

* If a commit has yet to make it into the central repo, then it has no ID, or perhaps only an unstable ID that might change or become invalid in the future. This does not matter, because these commits are considered "unfinished" and should not be used for any serious purpose (other than asking people to review them so that they can become final).
* Once a commit is in the central repo, history rewrites are forbidden (allowing for a few exceptional cases when some sensitive item gets improperly committed). The need to support that exceptional use case is one of the stronger arguments for using a non-DVCS system (which can simply assign numeric commit IDs by fiat rather than having to do this whole Merkle tree business, so you can rewrite history without changing subsequent IDs).
* When something is cherry picked, there is some notion of a "primary" or "original" commit, which will at the very least be mentioned in the commit message of the cherry pick. Good tooling can use this to resolve the original commit when given a cherry pick ID (not every org has good tooling).
* Linear history is usually enforced. When a commit becomes final, it is rebased on top of the intended branch. For some systems like Perforce, this is usually a trivial operation (Perforce's data model is that each individual file is a series of snapshots with associated numeric commit IDs, so all history is inherently linear, and "rebasing" just means "check to make sure that nobody else has edited any of the same files as us").

Obviously this would not work very well for Linux's use case, but it is the sort of thing that the MITRE people were probably expecting when they set some of these rules around stable IDs.