This issue stems from #115, albeit is now far less severe.
Thanks to the commits from that issue, this particular use case no longer crashes the plugin, nor does it stack trace.

Instead, however, it introduces some unintended behaviour.

Reproduction Setup

1. Make two portals
   
2. Make the right-most gate a normal networked gate on an empty network.

GateName1

NetworkName

3. Make the left-most gate an A networked gate on that same network; once selected, scroll to select the right portal.

GateName2

NetworkName
A

4. This gate will function as intended; try entering it.

5. Break the right portal and enter it again; the left gate will still work.
i.e. entities entering the left gate will still be transported to the right, now deactivated, gate; this is a bug.

6. This issue will be partially resolved when the server is restarted (at which time it becomes part of issue #125)

Possible Refinement Changes

• When trying to teleport the user to a portal, networked gates should check if the destination gate still exists.
• If it doesn't, the sending portal's iris should be deactivated and tpDestInvalid should be printed.

As of 58b4545, most of these problems have been resolved.
Having said that, there is still one network-related error:

Step 1: Create two gates on the same network
Step 2: Point gate 2 to gate 1 and open it
Step 3: Wait for it to close
Step 4: Select gate 2 on gate 1 and open
Step 5: Break gate 1

Gate 2 stays open.
Entering it will either TP you through the broken gate, or will take you to the nether.

Fixed for A gates in commit e347015.
Apparently, this problem also exists for normal networked gates
(although that is slightly less of an issue as the gates in question time out by themselves).

Notwithstanding a possible connection to issue #126, this problem and its derivatives appear to be fixed.