Here's how I personally see such a "bridge" working best:
1) The Singleton is a specialized channel type that acts as a special case "clone" (some limitations on what does/doesn't get "synchronized" may need to be added - see below).
2) Non-nomadic network addons can only be installed on a "singleton" channel
3) Nomadic channels can only access addresses of non-zot networks if they have a specialized "singleton connector" addon installed which links their channel to the singleton "clone". (A separate "singleton" addon is installed on the singleton itself)
4) ONLY the channel address of the singleton channel is ever seen by non-nomadic networks.
5) The "singleton connector" addon permits linking to no more than ONE singleton "bridge".
ADD CONNECTION/ADDRESS BOOK
If the "singleton connector" addon is installed, first attempt to look up the address via ZOT, then pass an API call to the singleton (via the "singleton connector") to see if it can make the connection via a non-nomadic network.
Unless the "singleton connector" addon is installed, a clone does not have the ability to specify non-zot addresses on outgoing messages or even "see" them in their address book - though - because of the message routing (see below), they should still see non-zot identities in conversations.
For outgoing (top level) messages from zot channel clones the singleton node is responsible to redistribute to non-nomadic addresses. (this is basically what I understand occurs now)
Incoming (top level) messages get forwarded ONLY to channel clones running the "singleton connector" (While not ABSOLUTELY necessary from a technical vantage point, the reason for this is to keep the user mindful that there is something special about connecting to non-zot network addresses. Also, the "singleton connector" can provide feedback and information about the health of the singleton relay node).
Incoming REPLIES to ZOT toplevel messages coming from non-zot networks are received by the singleton and follow the current rules for replies with the addition that a copy needs to be forwarded to each channel clone. (For thread continuity, I would NOT require that the "singleton connector" be installed on the clone if the message is a REPLY - otherwise the thread will have different views based on which clone is being used).
Outgoing REPLIES get treated as they do now (a copy going to each channel clone) with the singleton node responsible for redistributing to non-nomadic addresses.
If I am understanding things properly and if the latest round of "fixes" actually deals with the issues we've seen, MOST of this is actually what happens now. The only additional "layer" is the "singleton"/"singleton connector" addons which would serve as a trigger for enabling this functionality, provide a mechanism for user feedback regarding the health of the singleton node itself, and add the ability to add non-zot addresses from any channel clone running the "singleton connector" - not just the clone running the non-nomadic addons.
If I had the time and inclination - that is how I would approach things.