In recent projects, I regularly and increasingly encountered the need for meaningful, predictable node identifiers. Say for example you modeled your product catalog as nodes (which imho makes total sense regarding translations and other dimensions, workspaces etc.) and have related entities (import commands from external systems, quotable offers etc.) which need to be able to retrieve nodes from a given context (if not even directly from the NodeDataRepository) but are unaware of internal node identifiers that have been defined as UUIDs.
In the current implementation, it is possible to use custom identifiers, although by some ugly means (AOP, custom reference inspector, custom LinkingService to name some), because here and there, some rather half-heartedly implemented restrictions are in place. The reference editor shortens IDs to 40 characters, the NodeData implementation validates strings in reference properties against the UUID pattern (but only on publish, not on setProperty) etc.
I’d love to see those restrictions gone for good. While UUIDs are a totally sane, sensible fallback if no other logic is in place, I don’t see the need for them being enforced. Node identifiers only have to be unique within the current subgraph (aka context), for uniqueness in the whole graph we have the variant identifier (currently persistence object identifier). The other way around, during import I can easily use the same UUID twice to break the system anyways. UUIDs by themselves are no guarantee for uniqueness whatsoever.
Should be non-breaking and easily implemented, I’d like to target 3.1 for this