Libraries are independent, so changes you make to My Library won't automatically be transferred to a group or vice versa.

It's not a question of "local" vs. non-local. It's just your personal library vs. the group library. Normally you would just work from the group library, at least until the end of a project. Why do you feel you need to copy things back as you go?

One problem with sharing a collection is that the same items can exist in other collections of yours, so, for example, a note that you added while viewing the item in another collection would be shared with everyone that you've shared the collection with, possibly without your realizing it. Or someone in the group could make changes to the item that would affect it in your other collections. Keeping things in separate libraries makes the privacy and modification implications much clearer.

An improved ability to transfer data back and forth between libraries is planned, though, and we're also hoping to make it easier to share a subset of a library in a read-only manner.

Right, so that's why you'd generally want to work only off the group version while it exists.

One thing we're hoping to do is make it so that you could just drag the group collection back to your personal library to keep the changes from the group, but the details are a pretty complicated.

Basically, if you dragged a collection or items between libraries, Zotero would keep track of the link. (This actually already happens.) If you dragged a collection again, or dragged it back, Zotero would create subcollections and items in the target library to match the source library. New child items — notes and attachments — would be created. Items that were removed from the collection in the source library would be removed from the collection in the target library but remain in the target library root.

But then you have some tough questions:

1) Should subcollections in the target library that didn't exist in the source library be removed? That would let you match the source library, but it would risk wiping out a lot of organization.

2) If an item was changed in the source library, would the changes be applied to the item in the target library? Probably, but that would affect the item everywhere in the target library, so you would need to trust changes from the source library.

3) Would child items of items in the target library be removed if they didn't exist in the source library? Those might have been added by you in the target library or deleted in the source library. You probably usually wouldn't want those to be deleted, but it would mean that if you then immediately dragged the collection back in the other direction, those child items would be transferred to the other library.

I don't think these make sense as prefs (and neither do the current group settings in the General pane of the preferences, really), and they'd also be hard to answer in the abstract at drag time. But I could imagine a wizard at drag time that 1) asked you which categories of things to include in the copy (replacing that section of the prefs) and 2) presented panes for the different categories that showed a list of the destructive changes that would be made — subcollections that would be deleted, items that would be changed, child items that would be removed — that let you uncheck the ones you wanted to leave unchanged, with options to select or deselect all.

All of which is to say, this is why things currently work the way they do. But if we can come up with a workable plan here, we can improve this.

Dropbox et al. aren't really comparable. If you're editing a shared file in Dropbox, you do that within a folder that's clearly shared. In the case of Zotero, you could be adding notes within an unshared collection without realizing that the item is shared elsewhere. Many people take notes in Zotero while writing, so this wouldn't be a rare situation. If we did allow collection-level sharing, I think there would need to be an item-level indicator in the UI that showed an item was shared, even when viewing it in an unshared collection.

There's also the problem of linked files, which generally wouldn't be found by users sharing the collection. We don't allow linked files in groups because of this, and if we do support them down the line it will be by allowing the linked attachment base directory to be set on a per-group basis. So either linked files would have to be hidden from shared collections or you'd have to be able to set a linked attachment base directory for those as well.

Groups also allow easy transferring of ownership, which is important since storage usage is counted against the group owner.

Separate libraries avoid these problems (and possibly others I'm not thinking of) and are also the way Zotero sharing has worked for many years, so I think improving the experience of transferring data between libraries — with the sort of process I outline above — is the top priority.

That said, there are common use cases — say, a research assistant helping organize sources for a project — where some of these concerns would be less less important than lower-friction sharing, so that's something certainly we hope to work on in the future.

Since groups don't seem to work unless you have cloud storage through Zotero, that connection becomes even clearer.

That's incorrect. You don't need a subscription to use any part of Zotero. A subscription only gives you additional online storage space for synced files, and even then only the group owner needs a subscription.