I think this might be a reasonable compromise – because Pat states:
(3) One can makes inferences from a Version 5 UUID in a "Community of Trust" where Source Namespaces used to "sign" and objects are shared. Otherwise one can infer nothing else from a Version 4 or Version 5 UUID.
If you are in a community of trust you would know that you should use the optional property for whatever purpose your community has agreed to. Others outside that community would ignore that property.
Personally, I think the same could be true if UUID 5s could be used in the id field itself, but since people seem to think that might cause problems – this could work for everyone.
One more thing, Pat – does every TLO have immutable properties? As John mentioned, you are referring to CybOX objects, so it might be true for them, but for STIX objects, may not.
CybOX btw, could do something different as far as ids go…
Why not have a required identifier based on UUID4 (my preference) and an if vendors want a deterministic id then they can include an optional attribute for that. For systems that want to use that optional identifier it would provide support for.