As stated in CS170797 (https://www.ptc.com/en/support/article/CS170797) Products and Libraries use the same namespace, while projects have its own namespace .
THE PROBLEM
In the case of Products and Libraries, a user cannot check in an EPMdocument from a workspace, that already exists (Name/filename fields). Therefore, the user must either update the workspace from the commonspace, or rename the conflicts before checking in,. in this case, uniqueness is enforced.
In the case of Projects, uniqueness is NOT enforced, when the EPMdocument exists in other Projects, Products or Libraries. It is recommended that EPMdocument namespace between Products, Projects and Libraries be "common" and EPMdocument duplicate values (Name/filename fields), be "prevented" from having the ability to check In to Projects, the same way that is "currently" done with products and Libraries.
We have external users that routinely checking in EPMdocuments to projects, and in many cases assemblies that already exist in our Product context. Significant is time wasted finding attempting to resolve the uniqueness problems between PDM (Products/Libraries) and Projects. Resolve identity conflicts replace function is risky to use, and would required the collaboration manager to interrogate *each* model, or rename. In the case of rename (using Resolve identity conflicts), the conflicts can only be renamed one by one, and no ability to export a report from Resolve identity conflicts.
THE SOLUTION
The process of resolving the uniqueness problems are significant, and PREVENTING the ability for users to create conflicts (via settings, if the business requirement is a common namespace) should be implemented with high priority.
