Gates can be created which point to non-existant portals.

Behaviours

If the origin gate is normal (button-activated), when the user enters the iris, the iris will break.
The users will remain in the same spot; no error message will be printed.

If the origin gate is A (always-on), when the user enters the iris, they will be sent to the iris material's default dimension.
In the case of nether.gates, this means the user will be sent to the nether.

Causes

No Destination

If a fixed gate is created that points to a non-existant portal, this will occur.

thisGate
nonExistant <- doesn't exist.
network

thisGate
nonExistant <- doesn't exist.
network
a

Broken Destination (Fixed Gates)

If a valid fixed gate is created, but its destination is subsequently destroyed, this will occur.

thisGate
thatGate <-- exists.
network

thisGate
thatGate <-- exists.
network
a

Broken Destination (Networked Gates)

If a networked gate is pointed to an existent gate, and if that gate is subsequently destroyed before the user enters the origin portal, this will occur.

This particular version of the issue rarely occurs for normal (button-activated) gates.
It is particularly problematic however for networked a (for which a pointer can indefinitely persist).

thisGate

network

thisGate

network
a

This seems to be caused by @Thorinwasher 's fix for Stargates not saving destinations when a destination does not point to a valid portal.

de73d8c and c949c38 fix some bugs in the behavior of Stargates with invalid destinations. Inactive always-on Stargates have the closed iris material. If they should instead use the iris-open material and work as a wall, the behavior needs to be changed again.

I have now tested everything related to this bug.
The above commits appear to have resolved this issue.