Has anyone seen the following configuration?
In particular, I’d like to know how stable and scalable this approach would be. The other option is to have separate broker servers connected through a gateway, but I’ve heard bad things about gateways in the past.
Broker isn’t typically a source of stability issues.
If you do a sizing analysis, you’ll be able to determine if a single Broker can handle the load of everything or if you’ll need to apply segmentation.
I’m not sure that the “patterns” mentioned would matter in terms of stability nor scalability. It’s really just a sizing concern.
That said, if you find that a single Broker cannot handle the workload, then those patterns may be useful in terms of segmenting the workload. However, it may be more useful to segment along traffic patterns rather than design patterns.
I think I would be a bit concerned with this architecture. Two sets of different clusters using the same broker? Rob is correct about the stability of the broker. What concerns do you have about the gateway? You can also use JMS or Web Services to connect the two. If the two clusters are really responsible for separate things but with the need to exchange or subscribe to messages, I would lean towards keeping them separate and using a Gateway, JMS or Web Services.
JMS or web services is extra development work. Gateway is just configuration. I’m thinking about the original option, but having different broker instances on the same broker server, but in the same territory. I’ll have to see what PS thinks. I would have to disagree on stability though-- we’ve had a couple of issues with the broker that were visible to management.
Not a lot of extra work on the JMS or Web Service side but there is some. Broker gateways are not trival and do require some thought. That being said, they do work very well. Rob is correct about stability issues on the broker they are extremely rare, sorry you had one but that doesn’t make it commonplace. 
There is a difference between gateways and territories. I not sure about putting them into the same territory, I tend to like the one territory per cluster, a gateway, and then another territory for the other cluster. Usually the bad things you here about gateways are from folks who didn’t configure them properly or understand completely how they work. There is some complexity there.
Depending on how your overall architecture is going in and what you are trying to accomplish there maybe other options as well. For instance the BAM engine has a very nice web service data collector process. It allows you to send it process information, kpi’s etc via a web service interface without actually having the process engine manage the process, it’s pretty cool and can be used with technology out side of the webMethods platform as well.
“I’m thinking about the original option, but having different broker instances on the same broker server, but in the same territory.”
Such an approach will not contribute to stability nor scalability. What do you see as the benefit to such an arrangement?
I’m not clear on your goals. If you’re after stability and scalability, that will tend to lead to multiple Broker instances on different host machines, with integrations partitioned in some manner such that some connect to Broker A and others use Broker B.
I must point out again, that Broker isn’t typically the source of scalablity nor stability problems. IS is far more susceptible to these sorts of issues than is Broker. Sometimes, Broker gets the blame for IS issues. For example, documents piling up on the Broker queue is often blamed on Broker–“Broker isn’t delivering documents.” When in fact, IS isn’t retrieving the documents. (Many people think Broker pushes documents around–it doesn’t.)