This isn't something we're going to enforce. Collections aren't filesystem folders, where filename uniqueness is a core part of the design and user experience (triggering replace prompts when dragging), and it would create friction — when renaming, when dragging collections around, when syncing — for no reason. (Implementing this for syncing would also be a huge undertaking.) Collections are sorted alphabetically, and if you don't want two with the same name, you can just rename one after doing whatever it is you were doing originally.
I understand that enforcing this may require substantial effort. I would disagree however, that there is a substantial difference between file systems and the Zotero collections in terms of the user experience. Folder/file name uniqueness exists because these are system IDs, while Zotero uses separate system IDs not exposed to the user. In principle, one could do the same for files and folders. However, file/folder name is the means for the user to identify those objects. Folders are a set of hierarchically organized containers for structuring/organizing user's chunks of data, i.e., files. And file name is the primary user exposed means do distinguish one chunk of data from another, while the folder name is a means to distinguish one set of objects from another, grouped based on certain criteria. I do not see any sense in having files or folders with identical names within one container. For the same reason, having two collections with the same name is a recipe for data mess.
Personally, I can make sure that such a collision does not happen in my library. However, I would think that people intuitively expect that child collection names uniqueness is also controlled by the system.
That’s one particular use case for collections. In my most common workflow for collections, I use collections to indicate the database sources of items in a systematic review. In that case, I neither expect nor necessarily want Zotero to enforce non-duplication of collection names. This is particularly the case as i drag subcollections between different collections as part of the workflow.
@PChemGuy: I'm not saying it makes much sense to keep two collections with the same name in the same place permanently. That's probably something you want to fix. I'm saying that enforcing it would be a much worse solution.
It's not just about the technical effort — it's about the many new problems it would pointlessly create for users. It would mean that, if you dragged a collection to another collection, Zotero would need to prompt you to do something complicated and error-prone — replace the collection (losing data), merge items (and subcollections? recursively? what if those had the same name too? what if the set of items in each had important differences that were lost?), or cancel the operation (leaving the collection in a more difficult place in your library to resolve the problem). It would mean that if you and someone else in a library created a collection with the same name, you would get a conflict that was essentially impossible to show a conflict resolution window for, so it would have to automatically rename the collection and then sync that back to the other computers, possibly creating more conflicts.
It's just not necessary to create these and other obstacles for something entirely trivial to fix manually (which is presumably why many library-based (and even folder-based) programs don't enforce this, by design).
Upgrade Storage
Personally, I can make sure that such a collision does not happen in my library. However, I would think that people intuitively expect that child collection names uniqueness is also controlled by the system.
It's not just about the technical effort — it's about the many new problems it would pointlessly create for users. It would mean that, if you dragged a collection to another collection, Zotero would need to prompt you to do something complicated and error-prone — replace the collection (losing data), merge items (and subcollections? recursively? what if those had the same name too? what if the set of items in each had important differences that were lost?), or cancel the operation (leaving the collection in a more difficult place in your library to resolve the problem). It would mean that if you and someone else in a library created a collection with the same name, you would get a conflict that was essentially impossible to show a conflict resolution window for, so it would have to automatically rename the collection and then sync that back to the other computers, possibly creating more conflicts.
It's just not necessary to create these and other obstacles for something entirely trivial to fix manually (which is presumably why many library-based (and even folder-based) programs don't enforce this, by design).