BI dual landscape for upgrades

Question

We recently built a dual / parallel landscape for our BI system to support a support stack upgrade.   I've used the dual landscape concept for many years when doing ERP upgrades, and it has worked very well.   We thought a dual landscape for BI would work also.   However, we did not consider the automatically generated objects in BI.
What we found is that with 2 development systems, even though BI objects are created with the same logical name, the technical (generated) name will be different between the 2 systems.
Has anyone successfully implemented a dual-landscape for BI?   If so, how did you syncronize the technical names of objects between development systems without transporting the objects from one development system to the other?   Note: I'm of the opinion that you need to be extremely careful transporting objects between systems with different release/support pack levels and therefore avoid it at all costs . . .  Note 1090842 + several bad experiences.   Therefore, I am very unlikely to consider transporting the objects created in PSD to RLD as a valid solution.
The following is just an attempt to better describe the issue:
Production support landscape looks like this:
PSD  ->  BWP   (these systems have lower release/SP levels than the systems in the release landscape)
Release landscape looks like this:
RLD  ->  RLQ    -
>  Changes will eventually go to BWP after release/SP upgrade in BWP
Lets say queryA must be developed and transported to BWP prior to the release/SP upgrade in BWP.
In PSD queryA is created and gets assigned technical name 123456 and is transported to BWP.
In RLD queryA also gets created, but gets assigned technical name ABCDEF.
Sometime after the release/SP upgrade, when you are back to a single landscape (RLD -> RLQ -> BWP), a change needs to be made to queryA.   When you transport queryA to BWP, you end up with 2 queryA's, one with technical name 123456 and one with technical name ABCDEF.

Answer 1

Hey.  I worked for years in a dual landscape environment and at one point, some folks were actually looking at three paths all pointing to production.  The three path idea got squashed fairly quickly, but we had two landscapes for as long as I can remember.  So we essentially had:
PAD --> PAQ --> Prod
PBD --> PBQ --> Prod
This was very helpful to be able to work on major releases and upgrades while still allowing weekly maintenance releases.  I never looked for a document that deeply discussed the concept and pitfalls to watch out for. 
I will say the system synch-up could often become quite a pain.  This may sound a little crazy but we would transport from landscape A to landscape B but dual code from B to A.  This was because A was for the triannual major releases and upgrades and B was maintenance work.  There were times when we would transport both ways, but we tried to stay away from that (except for queries). 
The idea was that anything that went to prod as maintnenance, out of B, should be dual coded in parellel in A.  Then once a tri-annual type release went from A, all those new transports and dual coding would be moved to B.  This is how we kept everything in synhc and it worked rather well.  You always had to be careful around the time of the tri-annual go live, but that's to be expected. 
The only objects we had constant problems with werre queries.  I don't know of anything you can do about that.  We eventually decided to always transport queries between the two landscapes.  We would never manually dual code a query.  We would eventually get the duplicate query issue in production.  The pitfall here is if the same query is getting touched for maintenance and a major release... that was just something we had to workaround.  But we never had any major problems with transporting between the two landscapes.  The times it became a huge headache is when people would forget to dual code, or just plain to a bunch of prototyping in one of these environments when they should have been using a sandbox.
Not sure if I have answered your question, but hope this helps in some way.  At least you know plenty of us feel your pain!