Currently, this is the only valid iron door type:

It has been suggested that this should also be a valid iron door type (i.e. expanding the definition to include any contiguous surface of iron doors).

Currently, whether a Stargate can be blocked by an iron door checks if a stargate is exactly 1 block wide and 2 blocks tall. With this new definition, isn't the check, and thus the flag, pointless, as any Stargate can be blocked by an iron door/trapdoor combination?

Or are there some assumed limitations like the iris has to be one connected square? I don't think there exists any designs that cannot be blocked by iron doors if trapdoors can be used as well.

Currently, whether a Stargate can be blocked by an iron door checks if a stargate is exactly 1 block wide and 2 blocks tall. With this new definition, isn't the check, and thus the flag, pointless, as any Stargate can be blocked by an iron door/trapdoor combination?

Or are there some assumed limitations like the iris has to be one connected square? I don't think there exists any designs that cannot be blocked by iron doors if trapdoors can be used as well.

The current implementation was only made to handle a common nexus practice on old servers for 1x2 gates.
If we expand the definition of this practice to encompass surfaces wholly covered by any combination of iron doors and trapdoors, the size check does indeed become pointless.

The new check should probably just check the materials in front of the iris to determine if it is adequately covered with any combination of iron doors/trapdoors. We would probably also need to force any all trapdoors to their vertical state since they would otherwise require power to properly seal the portal.

(Looking through all the issues)

The new check should probably just check the materials in front of the iris to determine if it is adequately covered with any combination of iron doors/trapdoors. We would probably also need to force any all trapdoors to their vertical state since they would otherwise require power to properly seal the portal.

This does not necessarily need to be a stored flag, we could just check if this is the case whenever an portal is interacted with.

I have some issues with this suggestion though, as any solution to this would require a complicated checking algorithm which will take up server resources. I therefore don't really see the need for such a niche feature to be extended more than it is already.