Currently, it is possible to make interserver networks that either do not integrate with, or outright conflict with, matching local networks.
See issue #255.

The long-term solution to this should probably be to just extend local networks into interserver networks:

Take local custom network (foo).
Also take interserver network ❪foo❫.

Given:

• Portal Test1 on ❪foo❫ on Server1

Test1
 
foo
I

• Portal Test2 on ❪foo❫ on Server2

Test2
 
foo
I

• Portal Test3 on (foo) on Server1

Test3
 
foo
 

• Portal Test4 on (foo) on Server1

Test4
 
foo
 

The listed portals shown from interserver portal Test1 should look like this:

- Test1 -
> Test2 <
Test3
Test4

The listed portals shown from local portal test3 should look like this:

- Test3 -
> Test1 <
Test4
 

For the example test3, note that the interserver portal test1 would clearly be indicated as such by its colour.

As an exception to this rule, default networks should handled similar to how they already are.

Take local default network <@@ DEFAULT @@>.
For its interserver equivalent ❮ @@ DEFAULT @@❯, the handling should work as follows.

Given:

• Portal TestA on local [central] on Server1

TestA
 
central
 

• Portal TestB on local [central] on Server1

TestB
 
central
 

• Portal TestC on interserver 【central】 on Server1

TestC
 
central
 I

• Portal TestD on interserver 【default】 on Server2

TestD
 
default
 I

The listed portals shown from interserver portal TestA should look like this:

- TestA -
> TestB <
TestC

The listed portals shown from local portal testC should look like this:

- TestC -
> TestA <
TestB
TestC

For personal portals, the functionality should be identical to that described above for local custom networks.
For terminal portals, the functionality is not yet defined, but should likely be identical to that described above for default networks.

The general conflict handling for duplicate network names (as identified by our conflict management diagram in #237) should be extended for all interserver network gates.

This likely reflects a sweeping change in how interserver networks are implemented.
If this change is too extensive given the upcoming beta push, we can probably expand conflict management to treat the interserver scope as functionally independent for the interim.

Also, this change is probably expansive enough to require its own branch.

This is a great idea, here's some issues we would need to face for even trying to deal with interserver conflict management:

• We would need to store the names of all local networks with their name and related server in the database. This is so that, when a server instance starts up, it will know all the local networks that already exist
• Any creation of a local network would require to send a bungeecoord pluginmessage, saying a local network has been created. Otherwise when a local network has been created, it will not register for the other server instances

And, yes. This would require quite a refactor to work, including loads of testing. This should really not be in the parity update, but later on, so that we can release some kind of beta version

Also, when I think about it, conflict management could be exactly the same as for interserver portals, that is if we implement the same functionalities as I mentioned above.

The main logic behind this post is (when I think about it) whether to have network centered behavior, or portal centered behavior, generally portal centered behavior might make more sense, as it's easier to see the status of a portal, rather than that for a network.