At present, there are two ways to get data into a UUID object, an unchecked version and what's called the "Optional" version. So for instance, there's setFromData and setFromOptionalData. The difference is that the Optional version looks at the UUID bytes and if they are all 0's it clears the data store for the UUID, rendering it an Invalid UUID.
However, there was no apparatus for determining which of these two variants to use. The PDB version always uses the Optional version, the Darwin support code used both somewhat inconsistently. The ELF object file code uses the unchecked version. And the generic parts of the code sometimes use one and sometimes another. So the current approach is not very coherent.
On Darwin, treating all-zero's UUID's as significant is actually wrong behavior - so that needs to be changed. But that still leaves the system seeming arbitrary. For instance, SBModuleSpec::SetUUIDBytes uses the checked method. So even if some ObjectFile format treats UUID's of 0 as significant, you wouldn't be able to find it with SBModuleSpec.
My guess is this is all just historical and it would be fine to treat UUID's of 0 as meaning "not valid for matching", which is what this patch does.
If this is not the case, we'll have to add something like ObjectFile::AllZerosUUIDIsValid, and then check it everywhere outside the object file reader that we build UUID's. But I'd rather not do that if there isn't a compelling reason to do so.
The main reason this was a factory function was so that we could use the factory name to disambiguate between the two interpretations of zero "uuids".
As we're removing that, we could also go back to using regular constructors for object creation.