Using RTC 5.0, and we have the following setup for one of our RTC projects (let's call it Project_A):

Project_A has a stream that has its own project components, but it also inherits a component from an entirely separate RTC project on the same RTC server, let's call this Project_Z.

Project_A and Project_Z are using entirely different project processes, work item types, they have different personnel, team areas, separate customers and schedules, etc...

Because Project_A depends on Project_Z's component, whenever new changesets are made in Project_Z to fix/improve that project, Project_A accepts those changesets into their stream only -after- associating them with new Project_A work items so that they are tracked and peer-reviewed within the much more strict Project_A process structure.

Therefore whenever a changeset is accepted by Project_A from Project_Z, it will have at least work items associated: Project_Z's original work item that was done in Project_Z's project area, and another work item created under Project_A's project area that has additional process requirements (work item approvals, signoff, peer review, custom attributes, etc..._

The problem is that we want to restrict users from delivering a Project_Z changeset to Project_A's stream when it does -not- contain at least one Project_A work item in a specific state. This way we can track this new changeset within Project_A's reporting and have records of a peer review and approval, typical stringent process that Project_Z doesn't need to perform at all in their process.

In Project -> Process Configuration -> Team Configuration -> Source Control there are 2 preconditions that we were trying to use:
1. Deliver (client): 'Descriptive Change Sets' - The problem is that while you can verify that a changeset requires a work item, it doesn't have enough granular level to give what project's work items are acceptable. As long as it has -any- work items, it will allow the deliver. In our case, this doesn't work because we are looking for a very specific type of work item, specifically one originating from Project_A. So this will allow a delivery even if the changeset only has Project_Z work items associated.
2. Deliver (server): 'Require Work Items to Match Query' - The problem here is that the way RTC was setup to use a query to gate on work items, it will only verify against work items matching the parent project containing the query. Therefore you cannot do anything like 'make sure at least 1 work item associated contains a Project_A work item associated.' As per the jazz.net article https://jazz.net/library/article/1075#com.ibm.team.scm.server.workItemsMatchQueryDeliverAdvisor it states 2 reasons why this won't work:
    a. "This precondition verifies that the work items associated with each change set satisfy a work item query. In this context "satisfy" means the work item will appear when the query runs."
    b. "Work item queries can only match work items in their process area. The precondition allows the process author to dictate how work items from foreign process areas are handled: either allowed or denied."

The query doesn't fire and reject on #2 because if a changeset has -no- Project_A work items then the query result won't need to match against anything.