While fine in theory, I have some reservations about this feature. The main thing is that this sounds too complex for the typical user, so the effort for implementing this may not be justified considering the number of users who would potentially use this.

Also, considering that many users do not understand propositional logic, this, if adopted more widely, would probably require quite a lot of user support.

There are also technical issues: How would this be presented in the user interface in a way that is not confusing? Also, it is not immediately clear where this would sit well in the current technical architecture of Zotero: Consider the case of group libraries. Where would the rules reside, would they be library specific (like tags) or user specific. If they are user specific, how would you enforce a rule that you have created if also other can edit the tags?

The complexity of this feature from a users point of view is a valid and expected concern.

But adamsmith hits the nail right on the head: The full extent of this feature doesn't need to be available to the average user. It can be exposed through a GUI in a simpler form and still be available for geeks like me behind three levels of menus.

About the work: yes indeed. This would take some time to implement properly, though perhaps not as much as you're imagining. The constraint solving itself would be delegated to an existing backend, accessed through an API. Once clear design decisions have been made (and this, at least, is something I'd like to help with), the programming itself doesn't have to take all that long.

(Disclaimer: I am not familiar with the Zotero code/API. But I've been quite impressed with Zotero so far. I'm guessing it is set up in a sufficiently modular fashion to accommodate this feature.)

It will certainly be easier to go this route than to code ad-hoc solutions to many of those other feature requests. A bonus: many existing Zotero features might at some point be reimplemented in terms of this framework. Collections, notes, attachments, saved searches, ... could basically "be" tags, if only under the hood. This might greatly simplify the code-base.

mronkko: As for the technical issues you bring up: those are certainly points that require thinking about. Some preliminary responses:

The user interface

The user interface doesn't need to expose the full functionality. For mainstream use it's probably enough to allow the user to draw "requires" and "excludes" arrows between tags. Perhaps something akin to feature diagrams may be appropriate.

Where do the constraint rules belong?

Where do the constraint rules belong? Primarily, I think the rules should sit where the tags sit. Perhaps it is wise to make editing the rules a separate permission from editing the documents. Group administrators should be able to change the rules, but users with lower editing-rights should probably only be able to read them and 'be constrained' by them.

That being said, it would also be useful if users could set additional rules for their own personal experience. These rules would not affect other users of the library. When only virtual tags are affected by personal rules, there is of course no problem.

Broken constraints?

I suspected it would not be possible to prevent constraints from being broken in all situations, especially in a collaborative environment. It might also go wrong by syncing independent changes. But it's not a problem, as such. Documents with broken constraints could simply sit in a special folder until someone fixes the problem.

It might also be possible to figure out exactly which tags and rules are responsible for the conflict, and still let the document exist problem-free inside all unrelated tags. There is research on this, but it goes a bit beyond hard propositional logic (where a model either satisfies constraints or doesn't, no middle ground) and might be a bit too ambitious for now.