This ticket has originated with a installation using iRony 0.3.0 for CalDAV, backed by roundcubemail-plugins-kolab 3.2.3.
Either because of a former version or the current (latest) version of the software, a situation has been created in which a single folder has a `/vendor/kolab/uniqueid` metadata value in both the `/private` as well as the `/shared` namespace. Please note that, in addition, a `/shared/vendor/cmu/cyrus-imapd/uniqueid` folder metadata annotation is available.
Neither of the (three!) uniqueid values appear in cache tables, arguably indicating an error in the software; which this ticket is here to track and have verified (using functional and/or integration tests).
If the existence of these (multiple, different) metadata values is not disruptive to the software's operations, this should be verified with a test.
If the existence of these multiple and different metadata values is disruptive to the software's operations, then either the "garbage" needs to be cleaned up (can this be done automatically and autonomously?), the software needs to consistently choose and operate on the most consistent value for its purpose (i.e. `/shared/vendor/cmu/cyrus-imapd/uniqueid` or `/shared/vendor/kolab/uniqueid`, in that order, but not `/private/vendor/kolab/uniqueid` which is valid only from one particular perspective), or reliably "fail & bail" with the appropriate logging (so that an operations team can clean up the garbage).