This isn’t a universe design question, so I will move it into the Supervisor forum. The first thing you need to do is understand the difference between domains and repositories.
Separate repositories usually mean that each has an instance of the Security Domain tables plus at least one set of Universe/Document Domain tables.
They would typically be on different database servers – although it is conceivable that they could exist in different “partitions” of a given database server. In a Sybase server, they might be in different databases. In an Oracle server, they might be in different Schemas.
Just a question: Why are you “toying” with an outdated version 6.x instead of using XI R2?
If you wanted to create environments for DEV, TEST, and PROD for BusinessObjects ver 5.x/6.x the recommendation is to only create ONE security repository (which is referenced via the *.key file). Within that one security repository you create separate universe/document domains, one each for DEV, TEST, and PROD. This will allow you to use the Supervisor module to access all three universe/document domains at the same time and will make deployment of content (in particular WebIntelligence documents) from DEV–> TEST–> PROD easier.
As an (not recommended) alternative you could create 3 separate security repositories (one each for DEV, TEST, and PROD, each having their own *.key file), each with their own document and universe domain. This architecture will allow for a total separation of DEV, TEST, and PROD environments, but comes with a higher maintenance burden in particular when deploying content (WebIntelligence documents, universes, etc.) from DEV --> TEST --> PROD.
I allow myself to expose my point of view, have worked with organizations who present that scheme, repository of Development, repository of Test, and repository of Production, here more than nothing will depend on the policy of the user or organization, but of the equal most optimal way it is to have single repository with multiple domains I believe that also it could be court favorite, but will depend on the necessities and policies of each user or organization again