pfSense

Edit an interface. Choose "Static IPv4" and/or "Static IPv6".
Click the "Add a new gateway" button.

Scenario 1: Enter an invalid IPv4/IPv6 address for the gateway and click add.
An input error message is displayed, the gateway is not created - good.
But the gateway is added to the dropdown list on the interface edit page, and is selected.
When the user tries to save the interface, an error is given because the selected gateway does not exist.

Easy enough to work around for the user, but if there is an error creating the gateway it really should not be added to the list for selection.

Scenario 2: Enter some (valid) IPv4/IPv6 address for the gateway that is not in the subnet that you are going to define for the interface.
The gateway is created (because at this point there is no way to know what IP address/subnet the user will actually enter for the interface).
Enter some IP address/subnet for the interface which does not include the gateway, but still select the gateway.
Press Save
No error is given, but now you have an interface with a gateway defined that is out of the subnet.
Actually this is allowed, if the advanced gateway option "Use non-local gateway" is selected. But that cannot be selected from the gateway popup in the interfaces page.

Part of the problem here is that a 2-stage "transaction" is being done, but which needs cross-validation of the interface and gateway data. The process is not so "RESTful". One way to re-engineer it is:
1) Gather the gateway parameters, but hold them until the user presses Save on the interface.
2) Then POST all the interface and gateway parameters together.
3) If a new gateway is POSTed, then validate those parameters (as well as the interface parameters)
4) If everything validates, then create the gateway, and set all the interface parameters as a single "transaction".
5) If there is a validation error with either gateway or interface parameters, then do not save anything. Display the validation errors to the user.

That will require some refactoring of validation and saving code, so that a gateway can be validated and then saved by calling proper functions for that - rather than the current system where that "business logic" is embedded in the system_gateways_edit.php GUI page code.

(On a system-wide basis this is an architecture issue with almost all the code. There are no nice functions (methods) to call to validate an "object" (interface, gateway, rule, alias, NAT etc... parameter set) and then add/modify that object in the config. That code is in-line in each GUI page. So it is not [easy|possible] to have multiple GUI pages that "cross-POST-update" various combinations of the config "objects".)