Hi Guy,
I have only seen single instances of RRC too. I feel like it would be natural for decision makers to prioritize requirements from multiple customers or multiple products with using different projects over one single instance (with the same public URL.) When it comes to RTC, RQM, I would say instances could be different because developers and testers would be different.

If you look at this article  https://jazz.net/library/article/853  and specifically  Illustration 3: Overview of the CICS Jazz server architecture, towards the end,  you will see an example with several RRC instances, where one is used for the overall customer perspective and then other instances of RRC for individual product projects.

In general RRC requirements tend to have more a business focus that span multiple systems, products and releases, where specific milestone requirements maybe be contained in RTC as stories.

I'm a long time user of RequisitePro and Rational Requirement Composer.
 
Its my opinion that Product and Client Solution requirements should be managed separately as our clients' solutions often will incorporate many IBM products and technologies, not to mention non-functional solution requirements and solution deployment requirements.  Thus it’s my preference and practice to capture and refine a customer's requirements separately from one another and then associated them to the products and technology that best address them.  

As I work with customers I keep individual customer requirements separate from each other while refining them to simplify how I work with my customers.   My approach is to refine customer business needs to IT requirements that map to the capabilities of IBM products (new and existing) and other emerging technologies.  For me as a customer facing IT solution architect its pretty black and white.  I don't want my Nation Wide Insurance requirements mixed with my American Airlines or REX Hospital requirements.

If your organization is responsible for rolling out the complete solutions, I cannot envision managing the engagement any other way.  However, If your organization is product focused and solely responsible for developing product offerings, I can see that combining all customer requirements into a single RRC instance would be tempting and could make sense in many cases.   For organizations that have both solutions and product development responsibilities, the black and white lines become blurred.  In working with customers who have requirements that are complex and diverse where a subset of their requirements contribute heavily to 1 or more than 1 product’s direction, I think it’s appropriate to manage their requirements separately as solution requirements.   On the other hand, if you have 10 or 50 other customers who only contribute a few requirements to a product’s direction, I can see grouping them together in a common RRC project to minimize administrative tasks and costs.  Of course for these 10 or 50 customers, their other solution requirements will still need to be managed by the services organization.

Linking the individual customer requirements in RRC projects to specific products (managed in RTC) is how requirements are consolidated for each product that a Development team is producing.  This linkage is one mechanism of how customer requirements can be prioritized as product requirements (Requirement Z is linked to 6 customers). Of course not all customer requirements are linked to products under development, thus they would not be linked to a development teams RTC projects.

Requirements that are best addressed by a new product’s capabilities (features in plan or features yet to be prioritized to be in plan) would first be captured in RRC and refined - maybe as a high level business requirement and then refined to one or more system level requirements before being linked to a product’s RTC project.  This linkage is a primary feature of the Rational CLM tools - you select a RRC customer Requirement (system level) and simply create a link (via the RRC User Interface) that renders the customer requirement as an artifact in a Product RTC project to be prioritized into a Sprint.

One Example of a CLM Environment